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SECTION  1 


INTRODUCTION 


1.1.  Overview 


Foreword  This  section  presents  the  purpose,  scope,  and  context  of  the  Coast  Guard  (CG) 

fleet  logistics  Data  Administration  Plans  and  Procedures  (DAPAP)  manual.  This 
document  is  written  for: 

•  Information  system  developers  and  maintainers  (i.e.,  those  responsible  for 
maintaining  current  systems  and  creating  new  ones) 

•  Administrators  and  users  of  information  systems  that  create  and/or  use 
logistics  information,  including  users  who  write  SQL-based  inquiries  and 
reports 

•  Program  managers,  planners,  and  system  acquisition  personnel 

•  Data  administrators  and  data  stewards  who  develop  data  standards  for 
developers  and  users. 

This  manual  is  necessary  because  the  CG  is  developing  and  maintaining  fleet 
logistics  information  systems  that  share  data  with  other  organizations.  To 
accomplish  this  level  of  data  sharing,  a  consistent  set  of  data  standards,  guidelines, 
and  processes  is  necessary  to  ensure  reliable,  efficient,  and  high-quality  data 
sharing  inside  and  outside  the  CG.  This  approach  supports  the  CG’s  data  element 
standardization  initiative  while  at  the  same  time  it  enables  fleet  logistics 
information  systems  to  share  data  with  customers  and  suppliers  outside  the  CG. 
The  primary  benefit  of  this  initiative  is  to  provide  a  more  complete,  reliable, 
timely,  and  accessible  information  resource  to  all  CG  personnel  who  use  fleet 
logistics  information. 


In  this  Section  This  section  contains  information  on  the  following  topics: 


Topic 

Section 

Purpose  of  This  Document 

1.1 

Scope 

1.2 

Background 

1.3 

Related  Documents 

1.4 

Organization  of  This  Document 

1.5 

Introduction 


1.2.  Purpose 


Introduction  This  manual  provides  uniform  guidance  for  the  implementation  of  data 

administration  within  standard  fleet  logistics  information  systems.  This  manual 
implements  CG  information  resource  management  (IRM)  standards,  other 
Government  agency  and  industry  standards,  and  information  systems  engineering 
principles.  Its  orientation  is  not  to  teach  information  systems  engineering,  but 
rather  to  provide  achievable  processes  that  permit  CG  information  systems  users  to 
share  information  reliably  and  efficiently. 


Document  This  manual  describes  a  proactive  data  administration  (DA)  program  for  Coast 
Objectives  Guard  fleet  logistics  information  systems.  The  fleet  logistics  DA  program  is 
described  in  Section  2.  This  DA  program  provides  significant  benefits  to 
information  system  developers,  to  the  users  of  the  information  in  these  systems, 
and  to  the  efficient  operation  of  the  CG.  To  implement  the  fleet  logistics  DA 
program,  this  manual  has  the  following  objectives: 

1.  Describe  a  system  of  guidelines  and  business  processes  which,  when 
implemented,  will  ensure  efficient  sharing  of  consistent  data  among  the 
systems  that  have  been  designed  to  meet  this  data  interchange  requirement. 

2.  Provide  definitions  and  concept  summaries  that  explain  the  guidelines  and 
process 

3.  Provide  guidance  and  direction  for  logistics  data  administration  and  its 
customers. 

4.  Allocate  roles,  responsibilities  and  relationships  among  fleet  logistics  data 
administration,  logistics  functional  organizations,  and  systems  development 
groups. 

5.  Set  a  standard  for  multi-enterprise  data  sharing  that  meets  CG,  other 
Government  agency,  and  industry  standards,  and  anticipates  the  increasing 
demand  for  wider  sharing  of  information  resources. 

6.  Provide  a  basis  for  planning  and  managing  the  development  of  coordinated, 
standard  information  systems. 

7.  Serve  as  the  operational  framework  and  guidance  for  implementing  detailed 
Fleet  Logistics  data  administration  procedures. 

8.  Describe  what  fleet  logistics  data  administration  is  doing  to  support  fleet 
logistics  functions,  while  responding  to  CG  data  administration  standards  and 
IRM  policy. 
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1.3.  Scope 


The  Fleet  The  enterprise  currently  covered  by  this  manual  is  CG  fleet  logistics  operations. 

Logistics  Use  of  the  term  “enterprise”  in  this  manual  refers  exclusively  to  the  fleet  logistics 

Enterprise  enterprise,  not  the  corporate  CG  enterprise  as  a  whole. 

A  data  administration  program  is  implemented  for  an  enterprise,  that  is,  an 
identifiable  organization  that  works  together  to  accomplish  a  mission.  The  scope  of 
the  enterprise  is  likely  to  evolve  over  time  as  the  requirement  and  opportunity  for 
information  sharing  increases. 

Fleet  logistics  is  not  a  single  CG  organization,  but  is  a  collection  of  supply, 
maintenance,  and  shipboard  configuration  management  functions  that  have  created 
a  community  of  interest  across  several  organizations.  The  use  of  this  generic  term 
is  meant  to  emphasize  the  critical  nature  of  the  information  shared  by  fleet 
logistics  functions. 

Because  the  scope  of  the  enterprise  is  likely  to  expand,  planners,  information 
system  architects,  and  data  stewards  are  encouraged  to  look  beyond  the  fleet 
logistics  enterprise,  to  design-in  compatibility  with  other  CG,  other  Government 
agency,  and  industry  information  systems.  Refer  to  “Evolution  of  the  Enterprise” 
later  in  this  section. 


Data 

Administration 


DOD  8320.1  describes  DA  as  "...  procedures,  guidelines,  and  methods  for  effective 
data  planning,  analysis,  standards,  modeling,  configuration  management,  storage, 
retrieval,  protection,  validation,  and  documentation." 

This  DA  program  includes  a  data  modeling  and  data  element  definition  process, 
data  administrators,  data  stewards,  a  tailored  set  of  standards  and  guidelines,  and  a 
repository.  Section  2  describes  the  components  of  the  program.  The  DA  program 
depends  on  participation  by  various  CG  communities,  including  acquisition, 
mission  area  management,  information  system  users,  and  system  developers, 
maintainers,  and  administrators. 


Data  administration  (DA)  performs  “the  management  of  information  describing  the 
data,  functions,  operations,  and  structure  of  both  manual  and  automatic  data 
processing  systems  and  databases.. .throughout  the  information  systems  life  cycle.” 
[NIST  Special  Pub  500-173]. 
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1.3.  Scope,  Continued 


Fleet  Logistics 
Data 

Administration 


neet  logistics  data  administration  (DA)  is  responsible  for  overseeing  the 
management  of  logistics  data  across  fleet  logistics  functions  and  for  overall 
information  planning  and  control.  This  manual  brings  together  into  a  single 
document  the  responsibilities  for  logistics  data  otherwise  identified  in  data 
administration  procedures,  functional  process  improvement  procedures,  logistics 
business  plans,  and  other  fleet  logistics  planning  documents. 

The  fleet  logistics  data  administration  program  covers  the  following  areas  of 
responsibility  with  respect  to  fleet  logistics  information  system. 

1 .  Data  used  by  CG  Engineering  Logistics  and  fleet  supply  and  maintenance 
personnel,  and  data  used  by  cutter  personnel  for  shipboard  configuration 
management 

2.  Technical  development,  including  strategic  data  planning,  information 
management,  data  definition,  interface  design,  and  database  design  for  fleet 
logistics  information  systems 

3.  All  functions  not  otherwise  assigned  that  affect  data  quality,  integrity,  or 
security  for  information  processed  by  or  shared  between  fleet  logistics 
information  systems. 

Figure  1-1  shows  the  current  relationship  between  the  fleet  logistics  DA  program 
and  the  CG  DA  program.  It  also  shows  the  process  for  evolution  of  fleet  logistics 
(and  other  division-level  enterprises)  into  a  unified  CG  enterprise. 


Coordination  of  Fleet  Logistics  and  CG  Data  Standards 


CG  Operations 
&  Commands 

CG  Personnel 
&  Training 

CG  Nav.  Safety  & 
Waterway  Svcs 

CG  Readiness 
&  Reserve 

Other  CG  Offices 
&  Functions 


Premise:  Fleet  logistics  shares  more  data  with  DoD  agencies 
and  industry  suppliers  than  it  does  with  CG  organizations. 
This  rado  will  cl^ge  as  the  CG  enterprise  shares  more  data. 


Figure  l-l.  Relationship  of  Fleet  Logistics  and  Coast  Guard  DA 
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1 .3.  Scop6,  Continued 

Evolution  of  The  fleet  logistics  DA  program  must  support  data  exchange  with  a  variety  of 
the  Enterprise  Government  agencies  outside  the  Coast  Guard.  Today,  the  subset  of  DoD  and 
Coast  Guard  metadata  standards  that  permits  dual  compliance  must  guide  the 
DAPAP  instructions  to  fleet  logistics  information  system  developers.  In  the 
future,  we  anticipate  that  a  DoD-wide,  and  later  a  Government-wide  enterprise 
model  and  metadata  standard  will  develop.  Then,  the  dual  compliance  standard 
will  become  unnecessary  because  the  Coast  Guard's  metadata  standard  will 
evolve  to  meet  the  Government-wide  standard.  So,  efforts  both  at  the  fleet 
logistics  enterprise  level  and  the  Coast  Guard  level  that  move  toward 
Government-wide  information  interchange  are  strategically  appropriate. 


Areas  This  guidance  document  addresses,  in  addition  to  DA  operational  services. 

Addressed  program  management,  strategic  data  and  resource  planning,  business  process 
improvement,  and  technical  infrastructure  provisioning. 


Parts  of  the  A  coordinated  set  of  data  administration  processes  includes  an  enterprise  data 

DA  Program  repository,  an  evolving  enterprise  data  model,  data  stewardship  program,  data 

modeling  standards,  strategic  data  planning,  and  an  outreach  and  technical  support 
function.  This  manual  describes  this  set  of  DA  processes.  Clearly,  all  processes 
will  not  be  fully  funded  and  operational  at  the  outset.  This  manual  provides  a  basis 
for  a  master  plan  that,  if  followed,  will  result  in  an  efficient  and  effective  DA 
program,  benefitting  the  fleet  logistics  community  and  ultimately  the  corporate 
Coast  Guard  enterprise. 

The  CG  is  implementing  a  proactive  information  resource  management  program 
through  a  series  of  Commandant's  Instructions.  COMDTINST  5230.41 ,  Information 
Resource  Management,  provides  policy  and  direction  for  the  initiative. 
COMDTINST  5231 .2,  Planning  Approval  for  Automated  Information  Systems,  sets 
a  process  for  initiating  an  information  system  development  program.  COMDTINST 
5230.42  is  as  a  standard  for  naming  and  defining  data  elements. 

Other  standards  are  in  development,  at  the  CG  or  logistics  level.  Other 
Government  and  industry  standards  provide  companion  standards  to  complete  the 
set  of  guidance.  These  standards  include  process  and  data  modeling,  configuration 
management  of  metadata  (including  the  process  for  submitting  and  reviewing  new 
and  updated  models  and  data  element  definitions),  strategic  data  planning,  criteria 
for  acceptance  of  application  systems  for  data  sharing,  coordination  of  metadata 
with  other  government  agencies,  a  data  stewardship  program,  operation  of  a  Coast 
Guard  metadata  repository,  and  a  program  of  outreach  (education,  tools  support, 
and  enforcement). 
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1 .3.  SC0p6,  Continued 


Benefits  of  an 
Effective  DA 
Program 


As  the  fleet  logistics  data  administration  program  evolves,  it  will  provide  the 
following  benefits  to  the  Coast  Guard: 

•  Reduce  data  conversion  and  system  incompatibility  expenses. 

•  Make  transparent  data  sharing  possible,  providing  benefits  of  coordination, 
analysis,  rapid  update,  decision  support. 

•  Increase  the  availability  of  valid,  current  data  to  authorized  users  and 
application  systems. 

•  Reduce  duplication  of  similar  data  across  systems,  thereby  improving  data 
quality  and  reducing  storage  costs. 

•  Reduce  time  to  develop  new  applications  by  reducing  the  extent  of  analysis 
needed  for  specific  systems  and  providing  precise  requirements  for  new 
application  work. 

•  Focus  staff  attention  on  improving  business  processes  and  information  flow. 

•  De-mystify  system  development  and  return  control  of  data  definitions  and 
responsibility  for  data  quality  to  the  primary  user  communities. 
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1.3.  SC0p6,  Continued 


Success  For  the  fleet  logistics  data  administration  program  to  provide  the  intended  benefits. 
Factors  for  the  DA  program  must  achieve  the  following  characteristics: 

Data  •  The  fleet  logistics  DA  program  must  provide  more  value  to  the  user  and 

Administra-  developer  communities  than  the  cost  incurred  for  data  standards  compliance, 

tion  •  The  DA  process  must  not  be  seen  as  a  bottleneck  to  information  system 

development. 

•  Information  system  developers  must  work  toward  the  goal  of  an  enterprise-wide 
data  resource  by  commitment  to  compatibility,  diligent  strategic  data  planning, 
reliance  on  the  enterprise  data  model,  minimizing  application-unique 
definitions,  and  proper  and  early  preparation  of  design  documents,  deliverable 
data  models,  and  change  requests. 

•  The  DA  program  must  enable  and  support  data  stewards  and  empower  user 
communities. 

•  Keepers  of  the  enterprise  data  model  must  keep  enterprise  metadata  at  a  high 
level,  so  the  next  application  (to  be  standardized)  will  be  accommodated  without 
significant  re-defining  of  standard  entities  or  data  elements. 

•  The  DA  program  will  enable  (through  initial  and  ongoing  education  and 
technical  support)  developers  to  use  DA  processes  and  metadata  and  to  develop 
standard  information  systems. 

•  The  DA  program  will  provide  timely  and  accurate  assessments  of  the  effect  of 
proposed  metadata  changes  on  current  standard  systems  and  interfaces. 

•  CG  divisions,  programs,  and  mission  areas  must  participate  by  providing 
experienced  and  authoritative  data  stewards,  identifying  specialized  subject 
matter  experts,  and  including  the  work  of  data  definition  and  process  modeling 
as  part  of  their  respective  process  improvement  programs 

•  CG  Senior  managers  and  program  managers  must  ensure  that  data 
administrators  participate  in  all  strategic  data  planning,  process  improvement, 
and  information  sharing  initiatives. 

•  Only  information  systems  that  follow  the  enterprise  data  standard  or  whose  data 
has  been  certified  (by  DA)  to  be  compatible  with  the  standard  will  be  allowed  to 
share  data  with  systems  that  do  meet  the  standard. 
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1 .3.  Scope,  Continued 


Applicability  The  Fleet  Logistics  Data  Administration  Plans  and  Procedures  (DAPAP)  manual 

applies  to: 

1 .  All  business  data  processed  by  CG  fleet  logistics  information  systems, 
regardless  of  application.  They  also  address  the  functions  related  to  the 
identification,  specification,  capture,  storage,  transformation,  distribution, 
utilization,  modification,  and  retirement  of  data. 

2.  Heet  logistics  data  administration  operational  services:  data  modeling,  data 
element  standardization,  data  security  (designation  of  access),  data  quality, 
database  administration,  data  configuration  management,  and  data  collection, 
synchronization,  and  distribution. 

3.  Fleet  logistics  processes,  information  systems,  and  data  (including  data 
elements,  codes,  and  values),  and  the  business  rules  for  generating  and 
modifying  data. 

4.  Logistics  near-term  initiatives,  migration  systems,  and  legacy  systems,  and 
their  data  models,  databases,  files,  records,  and  data  elements,  throughout  their 
life-cycles.  Legacy  systems  need  not  conform  to  the  guidance  in  this 
document  until  the  legacy  system  is  also  a  designated  migration  system  or 
unless  the  data  associated  with  the  legacy  system  is  the  only  data  supporting  a 
logistics  area,  which  makes  the  data  elements  migration  data  elements  by 
default. 
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1.4.  Background 


Introduction  This  subsection  describes  the  context  for  the  fleet  logistics  DA  program. 


Data  Sharing 
with  Other 
Agencies 


A  significant  portion  of  fleet  logistics  data  sharing  occurs  with  other  Government 
agencies,  especially  Defense  Logistics  Agency,  General  Services  Administration, 
and  the  Department  of  the  Navy.  Therefore,  fleet  logistics  applications  must 
store  data  in  a  format  and  with  definitions  that  are  compatible  with  Department 
of  Defense  (DoD)  and  other  Government  and  industry  data  standards. 


CG  DA  Coast  Guard  data  administration  is  evolving  toward  an  enterprise  information 

Initiatives  resource  management  capability.  This  capability  is  part  of  the  Coast  Guard's 

Information  Systems  Technology  Architecture,  as  described  in  COMDTTNST 
5230.45.  The  Coast  Guard  Data  Administrator  (G-TTC-3)  is  working  to  improve 
the  CG-wide  information  resource  as  more  Coast  Guard  organizations  begin  to 
utilize  enterprise-wide  data  sharing.  This  role  of  proactive  data  administration  is 
key  to  achieving  those  advantages. 

The  CG  data  administration  program  is  currently  collecting,  describing,  and 
coordinating  data  elements  and  evaluating  data  models  to  develop  a  descriptive 
and  supportive  enterprise  data  model  and  data  encyclopedia.  The  data 
encyclopedia  will  meet  requirements  of  an  Information  Resource  Dictionary 
System  (IRDS,  HPS  PUB  151).  COMDTINST  5230.45  states  the  intention  for 
Coast  Guard  information  systems  to  become  standards-driven  rather  than 
hardware-dependent.  To  achieve  this  open  architecture  and  application  portability, 
this  Instruction  cites  seven  types  of  services,  one  of  which  is  data  management 
services.  Structured  Query  Language  (SQL)  is  cited  as  the  "long-term  standard  for 
common  access  to  data  bases."  The  intention  is  clear  to  provide  data  sharing 
"among  disparate,  large  heterogeneous  and  distributed  databases."  For  SQL 
queries  and  reports  across  systems  to  be  possible  or  useful,  the  data  in  those 
systems  must  be  defined  consistently  and  compatibly.  Effective  and  proactive  data 
administration  and  metadata  standards  is  critical  to  the  success  of  the  goal  of  open 
data  sharing. 


Continued  on  next  page 
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1.4.  Background,  Continued 


Data  Sharing  The  most  reliable  means  to  ensure  that  data  elements  from  different  systems  truly 
through  describe  the  same  information  is  to  obtain  the  name  and  definition  (for  both 

Standards  systems)  from  an  authoritative  enterprise  data  model  and  metadata  repository.  The 

fleet  logistics  metadata  repository  is  described  in  Section  6.  Ensuring  that  the 
model,  the  entities,  and  the  data  element  definitions  describe  the  real-world 
information  is  the  responsibility  of  analysts,  information  system  engineers,  data 
administrators,  and  data  stewards. 


Even  in  non-automated  processes,  different  CG  commands,  each  ship,  and  the  two 
coasts  have  developed  subtle  differences  in  how  they  define  seemingly  clear  terms. 
The  nautical  axiom,  "different  ships,  different  splices"  cannot  be  condoned  in  data 
administration  or  system  integration.  Reliance  on  aliasing  and  data  mapping  to 
reconcile  data  from  unlike  systems  is  time-consuming,  and  results  in  commingling 
of  data  values  that  may  be  significantly  dissimilar  in  denotative  meaning,  level  of 
detail,  or  specificity.  Combined  data  fi’om  these  unlike  systems  may  thereby  cloud 
the  data  quality  of  the  rolled-up  report  or  query. 

To  avoid  the  problem  altogether,  data  stewards  and  subject  matter  experts  must 
determine  the  best  sharable  name,  attributes,  and  domain  for  each  standard  data 
element,  and  then  system  developers  must  use  this  metadata  to  build  integrated, 
standard  systems.  Then  the  data  values  can  be  shared,  reliably  and  without  further 
analysis,  across  all  standard  systems.  The  key  criterion  is  whether  the  values  from 
all  standard  systems  using  a  given  standard  data  element  can  be  shared  and 
combined  fi'eely. 


T ransparent  The  DA  program  establishes  a  common  architecture  from  which  shareable 

Data  Sharing  database  and  application  systems  can  be  developed.  By  "shareable"  data  we  mean 
data  stored  in  an  information  system  that  can  be  transferred  or  accessed  by  another, 
separately  developed  information  system  transparently,  that  is,  without  analysis, 
interpretation,  mapping,  or  conversion,  while  maintaining  data  quality. 

Transparent  sharing  of  data  requires  that  both  systems  have  been  designed  and 
built  using  the  same  (standard)  logical  data  model,  data  element  names,  and  data 
element  definitions.  A  consistent  and  proactive  data  administration  program 
ensures  that  the  information  collected  and  stored  in  all  standard  fleet  logistics 
information  systems  will  be  shareable  within  the  Coast  Guard,  with  other 
Government  agencies,  and  with  suppliers  and  customers  as  needed. 
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1.4.  Background,  Continued 


Strategic  Data  Information  systems  work  together  when  they  are  founded  on  a  common  corporate 
Planning  data  model,  and  when  they  use  the  standard  definitions  in  preference  to  local, 

independently-developed  variations.  Strategic  data  planning  advocates  separation 
of  data  from  the  applications  that  create  and  process  the  data,  establishment  of 
subject  area  databases,  and  agreement  on  validated  standard  metadata  definitions. 
In  most  approaches,  proactive  data  administration  starts  with  strategic  data 
planning. 

Strategic  data  planning  recognizes  the  enterprise's  data  as  a  resource  that  is 
separate  from  the  enterprise's  organizations,  functions,  locations,  or  software 
systems.  In  addition,  the  strategic  planners  estimate  the  scope  of  the  corporate  data 
resource  thirty  years  or  more  into  the  future,  and  attempt  to  predict  which  other 
organizations  will  be  included  in  data-sharing  arrangements.  These  decisions  must 
be  made  or  endorsed  by  the  enterprise's  senior  management  and  major 
stakeholders. 


Enterprise  Often  a  strategic  data  plan  is  built  upon  an  enterprise  data  model,  which  describes 
Data  Model  the  categories  of  information  (entities)  and  the  relationships  of  that  information,  as 
it  is  used  throughout  the  enterprise.  Experts  in  the  enterprise's  various  categories 
of  information  provide  complete  and  professional  definitions,  attributes,  and 
domains  for  the  data  elements  under  their  stewardship.  When  the  enterprise  data 
model  is  implemented  with  data  element  detail  (the  attributed  data  model),  then 
designers  of  individual  systems  can  select  from  the  central  standard  (the  enterprise 
data  encyclopedia)  the  definitions  they  need  to  build  their  respective  application 
data  models  and  physical  databases. 


Application 
Design  from 
Enterprise 
Model 


As  the  application  designers  select  standard  data  elements  that  meet  their  respective 
systems'  requirements,  they  may  find  a  few  data  items  that  are  not  yet  included  in  the 
enterprise  data  encyclopedia.  At  that  point,  the  designer  must  prepare  a  request  for  a 
new  or  modified  data  element  definition,  and  submit  it  for  review  and  disposition  by 
the  data  administrator  and  the  appropriate  data  stewards.  That  is  the  point  where  an 
application  developer  would  use  the  Instruction  (and  in  fleet  logistics  applications, 
the  DAPAP  manual)  to  create  and  submit  a  standard  data  element  name  and 
definition. 


Continued  on  next  page 
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1.4.  Background,  Continued 


Incentives  for 

Standard 

Systems 


The  DA  program  must  provide  incentives  that  will  ensure  compliance  with  DA 
processes.  Leadership  toward  the  goal  of  transparent  data  sharing  must  come 
from  each  command,  division,  and  program.  To  provide  the  benefits  of 
transparent  data  sharing,  a  set  of  incentives  such  as  the  following  must  be 
implemented; 

•  Submitters  of  metadata  change  requests  must  demonstrate  that  the 
requested  data  element  (or  modification)  does  not  currently  exist  in  the 
fleet  logistics  metadata  repository. 

•  Submitter  must  show  that  the  candidate  data  element  will  be  used  in  a 
system  that  utilizes  a  subset  of  the  fleet  logistics  enterprise  data  model. 

•  Candidate  data  elements  will  be  reviewed  by  the  appropriate  CG  or  other 
subject  matter  expert  as  part  of  the  data  stewardship  program.  The 
definition,  attributes,  and  name,  as  returned  by  the  data  steward,  will  be 
complete,  conform  to  applicable  regulations,  and  will  ensure  that  the  data 
values  will  be  shareable  among  the  widest  possible  range  of 
organizations  and  systems. 

•  Candidate  data  elements  and  other  metadata  change  requests  must  be 
reviewed  by  someone  (contractor  or  Federal  employee)  who  is 
responsible  for  the  technical  quality  of  metadata  submittals. 

•  Only  systems  whose  logical  data  model  and  attributed  data  model  are 
subsets  of  the  fleet  logistics  enterprise  data  model  will  be  certified  as 
standard  fleet  logistics  information  systems. 

•  Only  standard  CG  information  systems  are  eligible  to  read  and  contribute 
data  online  to  and  from  the  fleet  logistics  corporate  information  resource; 
all  others  must  request  and  submit  data  in  batch  mode  on  magnetic 
media,  for  filtering  and  conversion. 

Clearly,  some  of  these  measures  are  inter-dependent,  so  that  the  whole 
enforcement  and  incentive  system  works  to  encourage  design  of  standard 
systems. 


Continued  on  next  page 
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1.4.  Background,  Continued 


Key  Roles  of  Whether  fleet  logistics  DA  builds  an  enterprise  data  model  (top-down)  or  collects 
CM  and  Data  and  catalogs  standard  data  elements  (bottom-up),  the  metadata  will  change  over 

Stewardship  time.  As  a  dictionary  of  standard  data  elements  or  as  an  integrated  data  model, 

configuration  management  must  be  an  active  part  of  the  data  administration 
program.  As  current  isolated  systems  are  upgraded,  most  will  find  an  advantage 
in  sharing  information  with  other  systems  and  organizations,  and  so  will  seek  to 
standardize  their  metadata.  As  each  system  submits  metadata,  many  of  the  initial 
standard  definitions  will  require  rethinking  to  accommodate  the  wider 
perspective. 

An  effective  data  stewardship  program  will  minimize  repeated  revision  of  data 
element  definitions  by  providing  authoritative  and  independent  review.  This 
ongoing  process  of  informed  review,  assessment  of  impact  of  changes, 
coordination  with  other  organizations,  and  correction  of  discrepancies  will 
require  proactive  configuration  management  and  data  stewardship  efforts  that  are 
integrated  with  administration  of  metadata  standards. 


Configuration  management  (CM)  will  provide  a  central  version  control  and 
release  point  for  software  and  metadata.  Version  numbers  assigned  by  CM 
provide  the  link  between  versions  of  application  software  and  the  data  definitions 
associated  with  each  system. 
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1.5.  Related  Documents 


Introduction  The  fleet  logistics  DAPAP  provides  a  set  of  processes  and  standards  that  meet  CG 
and  other  agency  data  administration  standards.  The  following  references  were 
used  in  preparation  of  this  manual. 


Coast  Guard  COMDTINST  5224.8,  Coast  Guard  Total  Quality  Management  (TQM) 
Documents  Organizational  Structure  and  Training  Strategy 

COMDTINST  5230.41 ,  Information  Resource  Management 

COMDTINST  5230.42,  Data  Element  Naming  Standards 

COMDTINST  5230.44,  Annual  Coast  Guard  Information  Resources  Management 
(IRM)Plan 

COMDTINST  5230.45,  Information  Systems  Technology  Architecture 

COMDTINST  5231.2,  Planning  Approval  for  Automated  Information  Systems 
(AIS) 

COMDTINST  5500 A3,  Automated  Information  System  (AIS)  Security 
COMDTINST  551021,  Information  Security  Program 


Other  Defense  Information  Systems  Agency,  Technical  Reference  Model  for  Information 

Government  Management,  Version  1.2,  May,  1992 

Standards 

DOD  8320.1  (1991),  DoD  Data  Administration 

DOD  8320. 1  -M-1  (5/92),  Standard  Data  Element  Development  and  Maintenance 
Procedures 

FIPS  PUB-156,  rev.  5/89  (ANSI  X.3.138-1988),  Information  Resource  Dictionary 
System  (IRDS) 

MIL-STD-498  (5  December  1 994),  Software  Development  and  Documentation 

NIST  Special  Publication  500-173  (October  1989),  Guide  to  Data  Administration 

NIST  Special  Publication  500-208  (March  1993),  Manual  for  Data  Administration 

0MB  Circular  A- 130  (Revised  1994),  Management  of  F ederal  Information 
Resources 


Continued  on  next  page 
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1.5.  Related  Documents,  Continued 


Other  ANSI/IEEE  Std  1016-1987,  Recommended  Practice  for  Software  Design 

Publications  Descriptions 

ANSI/IEEE  Std  1074-1991,  Standard  for  Developing  Software  Life  Cycle 
Processes 

ANSI/IEEE  Std  1209-1993,  Recommended  Practice  for  the  Evaluation  and 
Selection  of  CASE  Tools 

Bracket,  Michael  H.,  Data  Sharing:  Using  a  Common  Data  Architecture;  New 
York:  John  Wiley  &  Sons,  1994 

Ganti,  Narsim,  and  William  Brayman,  The  Transition  of  Legacy  Systems  to  a 
Distributed  Architecture,  New  York:  John  Wiley  &  Sons,  Inc.,  1995 

King,  Judy,  Evaluating  Database  Management  Systems;  New  York:  Van  Nostrand 
Reinhold  Co.,  1981 

Martin,  James,  Information  Engineering;  Englewood  Cliffs:  Prentice  Hall,  1989 

Martin,  James,  and  Joe  Leben,  Strategic  Information  Planning  Methodologies; 
Englewood  Cliffs:  Prentice  Hall,  1989 

Redman,  Thomas  C.,  Data  Quality:  Management  and  Technology;  New  York: 
Bantam  Books,  1993 

Von  Halle,  Barbara,  and  David  Kull  (ed.).  Handbook  of  Data  Management; 
Boston:  Auerbach  Publications,  1993 
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1.6.  Organization  of  this  Manual 


Introduction  This  document  is  made  up  of  12  sections  plus  appendices,  and  is  organized  for 
easy  reference  and  maintenance.  The  figure  on  the  next  page  illustrates  this 
organization  and  the  relationships  between  the  sections. 


Section  The  following  table  describes  the  content  of  each  section. 

Contents 


Section 

Section  Title 

Description 

1 

Introduction 

Describes  the  purpose,  scope, 
applicability,  and  content  of  the  manual. 

2 

Fleet  Logistics  Data 
Administration  Program 

States  the  goals,  objectives,  and 
structure  of  the  Fleet  Logistics  data 
administration  program. 

3 

Support  Development  and 
Integration  of  Data  Models 

Shows  how  to  integrate  application  data 
models  into  an  enterprise  logical  data 
model,  the  foundation  for  effective 
information  sharing. 

4 

Standardize  Data  Elements 

Provides  a  consistent  process  for 
defining  and  naming  data  elements,  and 
a  process  for  submitting,  reviewing,  and 
modifying  DE  names  and  definitions. 

5 

Share  Data  by  Mapping  and 
Migration 

Shows  how  to  share  data  between  fleet 
logistics  standard  systems  and  other 
nonstandard  systems  without 
compromising  data  quality. 

6 

Maintain  Metadata  Repository 

Provides  the  operating  concept  for  a 
repository.  These  general  principles 
will  be  completed  later  when  a 
repository  tool  and  system  are  selected. 

7 

Control  Changes  to  Metadata 

Provides  a  process  for  DA  to  collect 
and  analyze  other  (legacy,  other 
organization)  metadata  for  planning  and 
consistency  purposes. 

Continued  on  next  page 
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1.6.  Organization  of  this  Manual,  continued 

Introduction 

Section  Contents  (continued) 

Ensure  Data  Quality 


Implement  Data  Stewardship 


Roles,  Responsibilities  & 
Relationships 


Data  Life  Cycle  Methodologies' 


12 

Data  Administration  Dictionary 
System 

Apx  A 

Information  Systems  Concepts 
for  DA 

Apx  B 

Class  Word  Descriptions 

Apx  C 

Data  Element  Attribute 
Descriptions 

Apx  D 

Forms 

Apx  E 

Glossary 

Shows  how  proactive  design  and 
definition  can  ensure  the  quality  of  data 
values. 


Returns  control  of  data  definition  to  the 
users  by  providing  a  system  of  subject 
matter  experts  and  data  stewards  for  all 
information  classes. 


Describes  the  functions  that  are 
performed,  identifies  who  must  perform 
them,  enumerates  the  responsibilities  of 
the  various  roles,  and  describes  the 
relationships  between  roles. 


Describes  the  evolution  of  data 
components  through  their  life  cycle  as 
presented  in  the  Fleet  Logistics  Life 
Cycle  Methodology  and  describes  the 
support  provided  by  the  technical 
infrastructure  for  the  program. 


Summarizes  the  functions  of  the  CG 
data  encyclopedia  (DADS). 


Provides  an  introduction  to  the  terms 
and  concepts  used  in  this  manual. 


Lists  and  defines  the  authorized  fleet 
logistics  class  words. 


Explains  the  attributes  to  be  tracked  for 
each  standard  data  element. 


Contains  forms  required  for  or 
beneficial  to  execution  of  procedures  in 
Section  3-11 


Provides  definitions  for  data 
administration  terms  and  abbreviations. 
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Introduction 


Functional 
Relationship 
of  the 
Sections 


The  DAPAP  sections  fall  into  the  following  general  categories: 

•  DA  program  overview 

•  DA  central  processes 

•  Supporting  DA  processes 

•  System  development  foundation 


Figure  1-2  shows  the  relationship  of  the  manual's  sections  to  these  categories.  The 
DA  function  supports  the  life  cycle  of  new  and  upgraded  information  systems. 
Four  supporting  processes  include  the  metadata  repository,  the  change  control 
process,  data  quality  criteria,  and  the  stewardship  program.  DA  has  three  primary 
processes,  which  are  data  modeling,  data  element  standardization,  and  reconciling 
legacy  data  with  the  fleet  logistics  standard.  The  first  two  sections  summarize  the 
DA  program.  Each  section  allocates  responsibilities  for  the  processes  described, 
and  Section  10  compiles  those  responsibilities  for  easier  reference.  The 
appendices  provide  tutorial  information,  a  glossary,  worksheets  and  forms,  and 
other  reference  material. 


Figure  1-3  shows  the  sections  recommended  for  initial  reading  by  segments  of  the 
intended  readership. 


Figure  1-2.  Visual  Table  of  Contents 


Continued  on  next  page 
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1.6.  Organization  of  this  Manual,  continued 


Reader  The  following  table  suggests  which  DAPAP  sections  would  be  most  useful  to  the 

Guidance  reader  who  has  specific  purposes  or  responsibilities. 


DAPAP  Reader  Information  Guidance 


1.  Introduction 

W 

W~ 

2.  DA  Program 

m 

F¥ 

M 

m 

3.  Data  Models 

m 

p/ 

S' 

4.  Std.  Data  Elements 

m 

m 

5.  Share  Data  (Map  &  Migrate) 

m 

6.  Metadata  Repository 

m 

m 

m 

7.  Change  Control 

! 

w 

M 

8.  Data  Quality 

9.  Data  Stewardship 

M 

M” 

1 0.  Roles  &  Responsibilities 

11.  Data  Life  Cycle  Methodologies 

w 

_ 

MI 

W 

W 

W 

Figure  1-3.  Reader's  Guide 
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SECTION  2 


FLEET  LOGISTICS  DATA  ADMINISTRATION  PROGRAM 
2.1.  Overview 


In  this  Section  This  section  states  the  objectives  of  the  fleet  logistics  data  administration  (DA) 
program  and  presents  the  phases  in  which  the  program  is  being  implemented. 


Topic 

Section 

Overview 

2.1 

Data  Administration  Goals  and  Objectives 

2.2 

Program  Overview 

2.3 

Program  Components 

2.4 

Program  Implementation 

2.5 

A  summary  of  the  information  systems  engirieering  concepts  behind  this  data 
administration  program  are  provided  in  Appendix  A. 


Why  a  Fleet  Information  systems  that  are  developed  to  meet  individual  program  needs  often 

Logistics  DA  lead  to  management  and  information  system  problems,  including  those  of 

Program?  conflicting,  erroneous,  and  redundant  data,  and  gaps  between  program-specific 

systems.  The  Information  Resource  Management  (IRM)  program  implemented 
in  COMDTINST  5230.41  utilizes  the  CG’s  infrastructure  of  standard  information 
technology  to  establish  cross-program  information  systems.  The  fleet  logistics 
functions  within  the  CG  will  benefit  from  this  IRM  approach. 

The  various  fleet  logistics  functions  and  organizations  share  as  much  data  with 
organizations  outside  the  CG  as  they  share  with  other  CG  systems.  Therefore, 
fleet  logistics  systems  must  be  designed  and  standardized  to  share  data  with  this 
wider  community  in  addition  to  meeting  CG  data  sharing  requirements. .  Data 
administration  (DA)  is  the  process  for  coordinating  and  optimizing  data 
definitions,  for  use  in  standard  systems  to  produce  shareable  data. 


Continued  on  next  page 


Fleet  Logistics  Data  Administration  Program 


2.1. 

Vision 


Overview,  continued 


The  fleet  logistics  DA  program  provides  a  set  of  processes,  mechanisms,  and 
guidelines  that  lead  to  standardization  of  data  structures  and  formats. 

Information  systems  that  define,  name,  format,  and  store  their  data  using  these 
guidelines  will  be  registered  as  meeting  the  fleet  logistics  metadata  standard 
("standard  systems").  Authorized  users  of  standard  systems  will  be  able  to  use 
data  without  regard  to  which  information  system  creates  or  stores  specific 
records  or  fields.  Data  can  be  shared  across  systems  without  additional  analysis 
or  conversion. 

Figure  2-1  shows  the  concept  of  creating  more  usable  information  from  the 
available  data  by  applying  data  standards.  Data  are  the  raw  values,  such  as 
numbers,  dates,  and  text  strings.  A  collection  of  data  becomes  information  when 
it  is  placed  in  a  meaningful  context.  If  the  context  is  consistent  for  the  data 
generated  by  many  systems,  then  all  the  data  generated  by  these  systems  becomes 
usable  by  all  authorized  parties.  Utilization  of  the  data  resource  is  cost-effective 
for  application  systems  because  each  system  can  use  (does  not  have  to  re¬ 
generate)  data  created  by  other  systems.  Fleet  logistics  operations  require 
effective  information  sharing  between  equipment  configurations,  vessel  status, 
procurements,  supply,  maintenance,  and  work  order  management,  for  example. 
An  added  benefit,  which  adds  considerable  cost  savings,  is  the  ability  to  analyze 
the  available  data  across  systems.  This  wider  view  of  the  data  enables  planners 
to  make  more  rapid  and  better-informed  decisions,  and  to  allocate  CG  resources 
where  they  are  needed. 


Continued  on  next  page 
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Fleet  Logistics  Data  Administration  Program 


2.1.  Overview,  Continued 


Relationship 
of  Data 
Standards 


Figure  2-2  shows  the  relationship  between  the  guidelines  presented  in  this 
manual  and  the  CG,  DoD,  commercial,  and  international  standards  cited.  Fleet 
logistics  data  administration  uses  Coast  Guard,  other  Government  agency,  and 
commercial  data  standards.  This  is  one  of  several  CG  enterprises  that  shares  data 
with  specific  categories  of  other  organizations  (and  so  each  enterprise  has  its 
respective  subset  of  data  requirements).  At  this  time,  the  fleet  logistics  enterprise 
does  not  share  data  with  international  organizations,  and  so  does  not  need  to 
tailor  its  data  requirements  to  international  standards  directly. 


Relationship  Fleet  logistics  information  systems  are  required  to  share  data  with  other  CG 

with  CG  DA  systems  in  addition  to  sharing  data  with  other  fleet  logistics,  other  Government 

agency,  and  private  sector  systems.  For  this  reason,  the  fleet  logistics  DA 
program  is  designed  to  meet  CG  as  well  as  other  agency  and  industry  metadata 
standards. 

To  ensure  that  data  values  created  by  fleet  logistics  cross-program  information 
systems  are  shareable  with  other  CG  systems,  the  fleet  logistics  DA  will 
coordinate  definitions  of  entities,  data  elements  and  other  metadata  with  the  CG 
Data  Administrator. 
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Fleet  Logistics  Data  Administration  Program 


2.2.  Data  Administration  Goals  and  Objectives 


Overview  The  mission,  goals,  and  objectives  described  in  this  section  were  approved  at  the 

outset  of  the  development  of  this  DA  program.  The  DA  program  is  designed  to 
achieve  this  mission  and  to  meet  these  goals  and  objectives. 

This  section  presents  the  goals  and  objectives  of  the  fleet  logistics  DA  program. 
The  next  section  describes  the  DA  program  that  is  designed  to  meet  these  goals 
and  objectives. 


In  support  of  the  CG  missions  of  supply,  maintenance,  shipboard  configuration 
management,  and  related  activities,  the  mission  of  fleet  logistics  DA  is: 

To  manage  and  ensure  the  quality  of  fleet  logistics  data  in  order  to 
enhance: 

•  The  understanding  and  definition  of  information  requirements 

•  The  development  of  automated  and  integrated  logistics  systems 

•  The  provision  of  usable,  reliable,  and  accessible  data. 


Goals  and  The  DA  program  is  focused  on  the  achievement  of  five  goals,  each  supported  by 
Objectives  a  number  of  objectives.  These  goals  provide  the  following: 

•  A  means  for  a  logistics-wide  shared  data  resource 

•  A  means  to  identify,  document,  and  maintain  data  requirements  and  data 
structures 

•  Improved  accessibility  and  ease  of  use  of  data  resources 

•  Methods  to  ensure  data  accuracy,  security,  integrity,  and  synchronization 

•  Processes  and  facilities  to  support  effective  data  administration. 

These  goals  and  their  respective  objectives  are  presented  in  the  following  table. 


Fleet 

Logistics  Data 
Administra¬ 
tion  Mission 


1. 

Provide  the  means  for  a  logistics-wide  shared  data  resource 
(common  building  blocks). 

a. 

Define  and  provide  standard  data  elements 

b. 

Enforce  the  use  of  standard  data  elements  in  engineering  logistics 
systems. 

c. 

Track  the  use  of  standard  data  elements  in  applications  and  subject 
area  databases. 

d. 

Provide  for  data  interchange  between  systems  and  among 
organizations,  e.g.,  protocols,  data  standards,  national  and 
international  standards  levels. 

e. 

Reduce  redundant  data. 

Continued  on  next  page 
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Fleet  Logistics  Data  Administration  Program 


2.2.  Data  Administration  Goals  and  Objectives,  Continued 


Goals  and  Objectives  (continued) 


2.  Identify,  document,  and  maintain  data  requirements  and  data 
structures,  (metadata) 


a.  Define  data  modeling  standards. 

b.  Model  fleet  logistics  business  processes  and  information 
requirements. 

c.  Integrate  data  models  into  a  central  repository. 

d.  Plan  long-range,  conceptual-level  information  requirements  for  the 

CG  fleet  logistics  enterprise. 

e.  Track  and  control  the  relationships  between  fleet  logistics 
conceptual,  logical,  and  physical  data. 

f.  Establish  and  conduct  a  data  stewardship  program,  by  information 
class. 

g.  Establish  processes  for  submittal,  review,  and  disposition  of  data 
definitions  and  data  requirements. 

h.  Provide  for  efficient  migration  of  data  from  legacy  to  successor 
systems. 

i.  Establish  a  common  glossary  of  terms  to  support  data 
standardization. 

3.  Improve  accessibUity  and  ease  of  use  of  the  data  resource. 

a.  Provide  inquiry  and  reporting  capabilities  through  accessible  data 
definitions. 

b.  Facilitate  data  accessibility  across  locations,  applications,  and 
platforms  by  providing  standards  and  mechanisms. 

4.  Ensure  data  quality  (accuracy,  security,  integrity,  and 

synchronization). 

a.  Define  procedures  to  control  consistency  and  accuracy  of  data 
definitions 

b.  Define  policies  and  procedures  required  to  protect  data. 

c.  Provide  rules  and  processes  for  assigning  data  stewardship 
responsibilities. 

d.  Maintain  links  between  data  models. 

e.  Provide  consistency  of  CG  data  definitions  with  those  of  allied 
agencies  and  private-sector  suppliers. 

f.  Consolidate  data  synchronization  requirements  and  determine  and 
resolve  the  internal  and  external  effect  of  changes. 

g.  Provide  for  conversion  and  validation  of  legacy  data. 

h.  Provide  the  means  for  analysis  of  data  access  and  data  use. 

Continued  on  next  page 
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Fleet  Logistics  Data  Administration  Program 


2.2.  Data  Administration  Goals  and  Objectives,  Continued 


Goals  and  Objectives  (continued) 


5.  Provide  processes  and  facilities  to  support  effective  data 

administration. 

a.  Establish  a  fleet  logistics  data  repository. 

b.  Provide  processes  for  defining  standard  data  objects. 

c.  Educate  the  information  system  developer,  data  steward  and 
mission  area  communities  in  effective  and  consistent  data 
administration  practices. 

d.  Provide  technical  support,  tools,  and  infrastructure  for  data 
administration  functions. 

e.  Provide  mechanisms  to  exchange  data  definitions  with  other 
agencies. 

f.  Provide  for  ongoing  evaluation  and  improvement  of  the 
engineering  logistics  data  administration  program. 
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Fleet  Logistics  Data  Administration  Program 


2.3.  Program  Overview 


Introduction  This  section  summarizes  the  functions,  processes,  and  resources  of  the  fleet 
logistics  DA  program.  The  next  section  describes  these  in  greater  detail,  and 
provides  links  to  supporting  information  in  the  remainder  of  the  manual.  The 
concepts  presented  here  are  essential  to  understanding  DA  processes  and 
functions. 

The  fleet  logistics  DA  program  crosses  organization  lines  with  the  purpose  of 
providing  a  high-quality,  easily  usable  information  resource  for  all  CG  personnel 
whose  work  includes  fleet  logistics  support. 


Guiding 
Principles  for 
Integrated  Data 
Management 


The  fleet  logistics  DA  program  adheres  to  these  guiding  principles: 

•  Data  is  a  shared  resource  that  should  be  defined  and  structured 
independent  of  applications. 

•  Data  should  be  treated  as  a  primary  and  vital  resource,  independent  of 
current  technology  and  systems. 

•  Standard  tools  and  facilities  should  be  used  throughout  an  organization  to 
manage  data. 

•  Users  should  be  given  the  tools  to  specify  and  retrieve  the  information  and 
reports  directly  from  a  common,  integrated  data  environment. 

•  Management  needs  to  be  involved  in  the  organization's  data  management 
strategy. 


Architectural  The  data  architecture  is  the  basic  structure  of  the  data  as  it  is  constituted  to  meet 
Framework  specific  requirements.  Data  architectures  are  represented  in  a  framework  having 
three  levels.  They  are  conceptual,  logical,  and  physical  levels.  Use  of  this  three- 
level  framework  provides  a  useful  link  between  high-level  unifying  concepts, 
information  systems  engineering  and  its  metadata  concepts,  and  the  design  of 
physical  databases  for  information  systems. 

This  three-level  architecture  is  implemented  in  requirements  for  the  fleet  logistics 
metadata  repository,  which  is  described  in  Section  6. 


Conceptual  The  conceptual  level  of  the  fleet  logistics  data  architecture  is  based  on  the 
Level  of  Data  following  concepts: 

Architecture  •  Subject  Area 

•  Information  Class 


The  conceptual  data  architecture  describes  the  kinds  of  information  used  in  the 
enterprise. 


Continued  on  next  page 
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Fleet  Logistics  Data  Administration  Program 


2.3.  Program  Overview,  continued 


Logical  Level 
of  Data 
Architecture 


The  logical  level  of  the  fleet  logistics  data  architecture  is  based  on  the  following 
concepts: 

•  Logical  Data  Model 

•  Entity 

•  Relationship 

•  Attribute  and  Standard  Data  Element 


The  logical  data  architecture  describes  each  of  the  specific  categories  and  items 
of  data  in  the  enterprise,  and  the  relationships  of  each.  This  level  describes  the 
data  independent  of  information  system,  CG  organization,  or  business  process 
because  most  data  items  are  used  by  more  than  one  system,  organization,  and/or 
process. 


Physical  The  physical  level  of  the  fleet  logistics  data  architecture  is  based  on  the 

Level  of  Data  following  concepts: 

Architecture  •  Physical  Data  Model 

•  Physical  File  /  Relational  Table 

•  Physical  Data  Field  /  Table  Column 

The  physical  data  architecture  represents  the  physical  design  of  objects  and 
databases  in  information  systems,  including  any  central  ("data  warehouse") 
server  resource  for  reference  data. 


Levels  and  Data  models  may  be  defined  on  different  levels  of  detail  (logical  entity-relationship 
Scope  of  Data  diagram,  logical  attributed  data  model,  physical  model). 

Models 

Data  models  can  also  be  defined  for  different  scopes  of  interest  or  views,  for 
example: 

•  Functional  {e.g.,  supply) 

•  Organizational  {e.g.,  Supply  Center  Curtis  Bay) 

•  Application  system  {e.g.,  CM+) 

•  Database  {e.g..  Cutter  System  File) 

•  User  view  {e.g.,  screen,  report) 

•  Data  flow  in  a  process  model  {e.g.,  alteration  data) 

In  the  current  (legacy)  systems,  these  data  models  may  have  inconsistencies 
between  systems  in  their  respective  definitions  of  similar  data  entities, 
relationships,  attributes,  and  physical  data  fields. 


Continued  on  next  page 


2-8 


Fleet  Logistics  Data  Administration  Program 


2.3.  Program  Overview,  continued 


Architecture 
Context  for 
DA 


Figure  2-3  shows  three  architectures  that  are  the  basis  of  any  information  system, 
and  the  views  of  the  four  major  stakeholder  groups.  This  figure  shows  the  issues 
for  implementing  the  fleet  logistics  data  architecture,  in  the  context  of  the  larger 
information  system  development  and  maintenance  effort. 


Data 

Architecture 

Functional 

Architecture 

Technical 

Architecture 

Owner's  . 

View  Conceptual 

Information  Important 
to  the  Busir^ss 

Mission,  Goals,  0^ectt\«s 
Critical  Success  Factors 

Data  Subjects,  Data  Classes 

Functions  /  Processes 
Performed  by  the 
Business 

Hardware,  Software, 
Network  Capabilities 
and  Limitations 

Geographic  Locations 

Architect's 

View  Logical 

Entity  Relationship 
Diagram 

Integrated  Data  Requirements 
Entities.  Relationships.  Views 

Function  /  Process 
Decomposition 
Diagram 

Diagram  of  Business 
Units  and  their 
Relationships 

Attributed  Data  Model 
of  Application/Database 

Tables,  Unique  Identifiers 
Attributes,  Integrity  Rules 

Risk/Quality/Synch.  Analysis 

Data  Flow  Diagram 

Process  Dependency 
Diagram 

Application  Information 
Systems  Interfaces 

Distributed  Systems 
Data  Exchanges 

Builder's  .  , 

View 

Database  Design 

Files,  Fields,  Indexes ,  Edits, 
Update  Propagation  Triggers 

Structure  Chart 

Data  Map,  Migration  Plan 

System  Architecture 

Hardware.Soflware,  Network 
Configuration 

Formal  Data  Design 

Coded  Data  Structures 

Data  Validation  Code 

Application 

Programs 

Network  Architecture 

Network  Addresses 
Communication  Protocols 
Physical  Network 

User's  ^  , 

View  OperaUona\ 

Actual  Data  Values 

in  Records,  Reports 
and  on  Screens 

Function/Action  Menus 
Operational  Actions 

Data  Dictionary 

Std.  Names,  Definitions,  Attributes 
Where-Used 

Figure  2-3.  Architectural  Context  of  DA  Program 
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2.3.  Program  Overview,  continued 


DA  Program  The  functions  of  the  fleet  logistics  DA  program  are  to  plan,  define  and  provide  a 
Functions  data  administration  infrastructure  to  support  fleet  logistics  business  processes  and 
use  of  the  corporate  information  resource.  Therefore,  the  data  administration 
infrastructure  includes  the  following  components: 

1.  Data  administration  operational  procedures 

•  Support  integration  of  data  models 

•  Standardize  data  elements 

•  Support  legacy  data  mapping  and  migration 

•  Ensure  data  quality 

•  Operate  repository 

•  Maintain  process  models  and  other  information  definitions 

2.  Methodology-dependent  data  development  deliverables  by  phase: 

•  Analysis  -  conceptual  entity-relationship  diagram 

•  Design  -  logical  data  model 

•  Construction  (coding)  -  physical  data  model 

•  Maintenance  -  data  definition  change  requests,  change  impacts 

3.  Modeling  techniques 

•  Data  administration  guidelines  for  data  modeling 

•  Review  of  data  models  and  other  metadata  deliverables 

4.  Computer-Aided  Software  Engineering  (CASE)  tools: 

•  Centralized  fleet  logistics  metadata  repository  with  utilities 

•  Data  modeling  tools 

•  Reverse  engineering  tools 

•  CASE  tool  export/import  utilities 

•  Data  quality  engineering  tools  {e.g.,  data  quality  filters) 

5.  Procedures  for  data  administration  operational  services 

•  Review  cycles 

•  Support  of  the  data  stewardship  program 

6.  Standards  for  data  modeling  and  data  definitions 

•  Quality  criteria 

•  Metadata  standards 

7.  Data  administration  education,  training,  and  coaching  services 

•  Education  and  outreach 

•  Technical  support 

•  Repository  information  services 


Continued  on  next  page 
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2.3.  Program  Overview,  continued 


DA  Working  Figure  2-4  shows  the  working  relationships  between  fleet  logistics  data 
Relationships  administration  and  the  various  user,  developer,  stewardship,  and  other 

organizations.  The  goal  of  reliable,  shareable  data  is  achieved  through  the 
cooperation  of  these  groups. 
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Figure  2-4.  Working  Relationships  for  Effective  Data  Standardization 


DA  Program 
Participants 


Fleet  logistics  data  administration  (DA)  involves  six  communities  of  interest: 

•  Users  of  fleet  logistics-related  information,  especially  those  who  require 
information  (such  as  aggregated  reports)  created  by  more  than  one  system 

•  Developers  and  maintainers  of  information  systems 

•  Acquisition  and  management  staff  v</h.o  plan,  procure,  and  implement 
information  systems 

•  Database  administrators,  network  administrators,  technical  support,  security 
specialists,  and  others  who  support  the  ongoing  operation  of  CG  information 
systems 

•  Data  stewards  and  subject  matter  experts  who  represent  CG  functional  areas 
and  users  of  specific  classes  of  information,  and  who  recommend 
improvements  to  the  enterprise's  data  definitions 

•  Data  administrators  who  provide  data  standards  support,  facilitation, 
reviews,  decisions,  reports,  and  repository  services. 

Most  DA  processes  require  participation  of,  or  cooperation  from,  two  or  more  of 

these  communities. 
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2.4.  Program  Components 


DA  Functions  Data  administration  functions  are  coordinated  through  the  fleet  logistics  DA,  but 
are  performed  by  people  in  various  organizations,  including  Engineering  Logistics, 
Acquisition,  and  cutters'  crew.  Figure  2-5  appears  complex,  but  it  represents  the 
information  flow  among  the  various  DA  functions.  Each  function  (represented  by 
an  oval  in  the  figure)  is  explained  following,  with  references  to  more  detailed 
descriptions  elsewhere  in  this  manual. 


USCG  Fleet  Logistics  Data  Administration  Processes 


DA  Planning  &  Evaluation 


Figure  2-5.  DA  Functions  and  Processes 


Continued  on  next  page 
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2.4.  Program  Components,  Continued 


DA  Program 
Management 


This  function  consists  of  the  following  activities: 

•  Plan  DA  program  strategy  and  tasks 

•  Acquire  and  organize  DA  resources 

•  Control  DA  tasks 

•  Evaluate  and  improve  DA  program  effectiveness 

•  Provide  leadership  and  advocacy  for  data  standardization  and  sharing. 


DA  Program  DA  program  staff  consists  of  CG  personnel  who  are  assigned  to  operate  and 
Staff  manage  the  fleet  logistics  DA  program.  This  function  is  the  point  of  contact  for 

DA  information,  clearinghouse  for  review  of  metadata-related  deliverables, 
approval  authority  for  standard  metadata,  steward  for  DA  resources,  and 
principal  advocate  for  transparent  data  sharing.  This  function  has  primary 
responsibility  for  the  quality,  efficiency,  and  effectiveness  of  the  fleet  logistics 
DA  program. 


DA 

Infrastructure 


This  function  consists  of  the  following  activities: 

•  Plan  target  integrated  data  administration  infrastructure 

•  Plan  data  administration  methods,  models  and  roles  for  fleet  logistics  life 
cycle 

•  Develop  data  administration  policies,  procedures,  and  standards 

•  Work  with  Acquisition  personnel  to  include  effective  metadata  requirements 
in  system  requirements  and  data  item  descriptions  (DIDs) 

•  Coordinate  with  other  agencies,  industry  groups,  and  standards  organizations 
to  define  fleet  logistics  data  so  that  it  can  be  shared  when  needed. 

•  Establish  data  stewardship  responsibilities 

•  Provide  and  support  data  administration  tools  and  facilities,  including  a 
reliable,  complete  and  accessible  metadata  repository 

•  Provide  data  administration  training  and  consultation  services 


Continued  on  next  page 
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2.4.  Program  Components,  continued 


DA  Tools,  The  technical  infrastructure  for  the  DA  program  includes  the  means  to  integrate, 
Facilities,  &  model,  analyze,  convert,  store,  and  review  metadata.  This  infrastructure  includes 
Support,  the  following  categories; 

•  Computers  and  communications  equipment 

•  Modeling  and  analysis  software 

•  Prototyping,  rapid  application  development,  and  SQL  query  software 

•  Data  quality  monitoring  and  filtering  software 

•  The  software  used  for  the  metadata  repository,  including  configuration 
management  (CM),  request  status  tracking,  and  review  facilitation  tools 

•  The  standards,  test  suites,  and  benchmarks  for  evaluating  standard  system 
candidates 

•  Training  materials  and  facilities 

Parts  of  this  infrastructure  are  operated  by  DA  program  management,  while  other 
parts  are  operated  by  other  organizations  in  the  fleet  logistics  community.  The 
distinguishing  factor  that  makes  a  tool  or  facility  part  of  the  fleet  logistics  DA 
infrastructure  is  the  commitment  to  allocate  a  major  part  of  its  use  to  facilitating 
transparent  data  sharing  in  the  fleet  logistics  community. 


Data  Models  The  focal  point  for  the  fleet  logistics  data  standard  is  the  enterprise  logical  data 
model.  This  logical  data  model  is  the  framework  that  implements  the 
information  classes  and  high-level  entities,  and  provides  reference  points  for 
relationships,  business  rules,  and  standard  data  elements.  In  addition  to  the 
enterprise  logical  data  model,  DA  also  collects  data  models  from  nonstandard, 
candidate,  and  other-agency  systems,  and  uses  these  models  to  better  understand 
how  information  is  used  by  various  CG  functions.  Section  3  provides  processes 
for  preparation,  submittal,  and  review  of  data  models.  Section  8  describes  the 
quality  criteria  to  be  used  for  reviewing  data  models. 


Data  Element 
Standardiza¬ 
tion 


In  an  established,  ongoing  DA  operation,  definition  and  refinement  of  standard 
data  elements  (DEs)  is  the  most  frequent  activity.  Standard  data  elements  are  the 
bridge  between  the  enterprise  data  model  (representing  the  fleet  logistics  view  of 
how  all  of  its  information  resources  are  used)  and  the  physical  design  of 
information  systems  (representing  that  application's  view  of  a  subset  of  the 
enterprise's  data).  The  quality  and  timeliness  of  standard  data  element  definitions 
will  directly  affect  the  speed  and  ease  with  which  the  fleet  logistics  enterprise 
reaches  its  goal  of  transparent  data  sharing.  Section  4  provides  processes  for 
preparation  and  review  of  proposals  for  new  data  elements  and  for  requests  for 
changes  to  current  standard  data  elements.  Section  8  provides  the  quality  criteria 
by  which  the  submittals  will  be  reviewed. 


Continued  on  next  page 
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2.4. 


Program  Components,  Continued 


Share  Data  Data  sharing  cannot  wait  for  all  CG  information  to  be  converted  into  standard 
from  Diverse  systems.  In  addition,  some  information  resides  in  systems  that  the  CG  does  not 
Systems  control,  or  which  have  been  designed  to  meet  other  standards.  Some  data, 

therefore,  will  require  mapping  so  that  it  can  be  shared.  In  all  cases,  the  mapping 
should  be  from  legacy  system  physical  fields  to  fleet  logistics  standard  data 
elements  (physical-to-logical  data  mapping).  The  more  significant  and  subtle 
problems  in  data  mapping  are  with  differences  in  definitions,  domains,  and 
business  rules  rather  than  with  names  and  attributes.  The  map  can  be 
implemented  by  changing  the  required  fields'  definitions  and/or  attributes  in  the 
legacy  system,  creating  a  translator  interface,  or  using  a  standard  system  as  a 
"broker"  to  convert  the  data  values  to  the  appropriate  format.  Processes  to  map 
data  in  legacy  systems  for  sharing,  and  to  migrate  legacy  data  to  standard  systems 
are  provided  in  Section  5,  Share  Data  by  Mapping  and  Migration. 


Maintain 

Metadata 

Repository 


The  fleet  logistics  metadata  repository  is  the  central  information  resource  for  the 
DA  program.  The  most  visible  function  of  the  repository  is  the  enterprise  data 
dictionary,  which  provides  definitions,  where-used  reports,  and  subset/view 
logical  data  models  to  users  and  developers.  The  repository  also  maintains 
information  class  definitions,  data  stewardship  assignments,  candidate  metadata 
changes,  review  status  for  metadata  change  requests,  metadata  for  legacy 
systems,  maps  between  legacy  data  and  standard  metadata,  and  implementation 
of  applicable  data  standards.  Section  6,  Maintain  Metadata  Repository, 
describes  this  key  DA  resource. 


Metadata  Changes  to  metadata  are  driven  by  changes  in  data  requirements,  and  by 

Change  improvement  in  understanding  of  business  processes  and  information.  The  fleet 

Control  logistics  metadata  repository  tracks  changes,  both  to  standard  metadata  and  to  the 

metadata  of  other  CG,  other  Government  agency,  and  private-sector  systems. 
Section  7,  Control  Changes  to  Metadata,  provides  processes  for  submitting  and 
tracking  changes. 


Continued  on  next  page 
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Ensure  Data  As  with  any  other  mission,  quality  is  part  of  the  fabric,  not  something  added  by 

Quality  &  one  action.  The  quality  components  that  improve  the  accuracy,  completeness, 

integrity  timeliness,  and  dependability  of  the  fleet  logistics  information  resource  each 

require  attention  and  action  by  information  system  developers  and  maintainers, 
database  and  system  administrators,  users,  data  administrators,  and  data  stewards. 
Aspects  of  the  DA  program  that  determine  the  quality  of  the  information  resource 
include  the  following: 

•  Ensuring  compliance  with  data  standards 

•  DA  education  and  outreach 

•  Facilitation  and  technical  support 

•  Criteria  for  metadata  review 

•  Acceptance  and  registration  of  standard  systems 

•  Modifications  to  and  exemptions  from  data  standards 

•  Control  access  to  non-public  information 

•  Risk  analysis  process 

•  Ensure  system-wide  data  synchronization 

•  Ensure  data  quality  and  integrity 

•  Implement  data  integrity  measures 

•  Establish  consistent  definition  of  terms  across  systems 

•  Improve  the  data  quality  program 

These  initiatives  are  described  in  detail  in  Section  8,  Ensure  Data  Quality. 

Data  A  data  steward  is  responsible  for  understanding  how  one  or  more  classes  of 

Stewardship  information  are  used  within  fleet  logistics  business  processes,  and  how  data  can 

be  shared  with  other  organizations.  Using  this  understanding,  the  steward 
establishes  authoritative  definitions  for  logical  entities  and  data  elements, 
reviews  requests  for  changes  in  data  element  attributes  and  definitions,  and 
represents  users  of  the  information  class.  In  these  functions,  the  steward  obtains 
support  of  subject  matter  experts  for  specific  technical  areas.  An  effective  and 
proactive  data  stewardship  program  will  place  responsibility  for  accurate  and 
complete  metadata  in  the  hands  of  the  most  expert  users  in  each  information 
class.  Section  9  describes  the  data  stewardship  program. 

Continued  on  next  page 
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2.4.  Program  Components,  continued 


Evaluate  DA  To  gain  acceptance  in  the  developer  and  user  communities,  the  DA  program  must 

Program  be  responsive,  effective,  supportive,  and  accurate.  As  with  the  data  values  the 

Effectiveness  program  describes,  the  standard  metadata  itself  must  be  accurate,  complete, 

timely,  and  dependable.  DA  business  processes  must  be  easy  to  implement,  and 
must  not  place  an  undue  burden  (aside  from  their  commitment  to  enterprise  data 
sharing)  onto  developers  and  users.  Metadata  change  request  review  cycles  must 
be  as  quick  and  definitive  as  possible.  The  fleet  logistics  DA  is  responsible  for 
the  effectiveness  of  this  program.  The  DA  will  maintain  program  effectiveness 
by; 

•  Monitoring  the  performance  of  the  DA  process 

•  Soliciting  developer  and  user  comments 

•  Providing  training  and  technical  support  to  participants 

•  Utilizing  the  available  technology 

•  Improvement  and  refinement  of  DA  business  processes. 

The  sections  describing  primary  DA  processes  each  provide  for  improvement  of 
those  processes.  These  process  improvement  subsections  are  placed  as  the  last 
pages  of  the  respective  sections. 
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2.5.  Program  Implementation 


Purpose  This  subsection  provides  a  phased  plan  for  implementing  the  fleet  logistics  DA 

program.  Depending  on  resources,  this  strategy  leads  to  full  implementation  of 
the  fleet  logistics  DA  program.  The  DA  implementation  phases  make  possible  an 
efficient  fleet  logistics  cross-program  information  system  in  achievable  steps. 


Working  This  approach  assumes  that  a  DA  function  is  in  place,  and  that  the  central  DA 

Assumptions  services  (such  as  metadata  review,  repository  operation,  standards  coordination, 

technical  support,  and  training)  will  be  provided  by  that  resource.  It  also 
assumes  initiatives  by  Acquisition  to  tailor  data-related  Data  Item  Descriptions 
(DIDs)  to  include  the  metadata  requirements  outlined  in  Section  11  and 
described  throughout  the  manual. 

Finally,  it  depends  upon  cooperation  and  commitment  of  the  management  of  fleet 
logistics  related  organizations  to  provide  data  stewards,  share  their  data  and 
migrate  their  respective  information  systems  toward  the  developing  standard.  If 
any  of  these  assumptions  prove  to  be  untrue,  the  implementation  strategy  and 
schedule  must  be  reconsidered. 


Implementation  Figure  2-5  shows  the  general  phases  for  implementation  of  the  fleet  logistics  data 
Phases  administration  program.  With  prerequisite  approvals,  funding,  and  cooperation, 

the  DA  program  can  be  operating  in  approximately  two  fiscal  years  by  following 
the  following  phases  and  associated  actions: 

•  Approval  of  processes  and  responsibilities:  The  foundation-laying  steps  that 
provide  the  basis  for  building  the  DA  program 

•  Funding  and  programming:  Allocating  and  developing  the  resources  that  the 
program  uses 

•  Deployment:  Moving  from  concept  to  action;  enabling  the  people  and 
configuring  the  resources  to  perform  DA  functions 

•  Operation:  Performing  the  DA  processes  (described  in  this  manual)  that  will 
build  the  desired  information  resource 


Continued  on  next  page 


2-18 


Fleet  Logistics  Data  Administration  Program 


2.5.  Program  Implementation,  Continued 


Implementation  Phases  Related  Activites 

for  the  Fleet  Logistics  DA  Program 


Develop  DA  Processes  &  Standards 
Allocate  Information  Classes 
Finalize  Repository  Requirements 
Plan  Repository  Implementation 
Plan  Develop  DA  Training 
Develop  Initial  DA  Budget 


Allocate  Responsibilities 
Recruit  Data  Stewards 
Staff  DA  Office 
Initiate  Enterprise  Data  Model 
Approve  Tailored  DIDs 
Procure  Repository  HW/SW 
Develop  Operating  Budget 


Include  DAPAP  &  DIDs  in  IS  Procurements 
Train  Data  Stewards  <&  DA  Staff 
Establish  Liaison  w/  DoD 
&  Industry  DA  &  Stds  Orgs 
Model  Primary  Business  Processes  (Stewards) 
Populate  Prelim.  Enterprise  Data  Model 
Stewards  Recruit  SMEs  (by  Info  Class) 
Inventory  Data  Where-Used 


Expand  &  Refme  Logical  Data  Model 
Review  Metadata  Change  Requests 
Coordinate  Data  Standards  with  CG, 
Other  Agencies,  and  Industry 
Provide  Outreach  Sc  Technical  Support 
Monitor  Quality  of  Data  Values 
Maintain  &  Share  Metadata 
Review  Metadata  Sc  Deliverable  Docs 
Review  &  Register  Std  Systems 
Provide  Repository  Services 
Improve  DA  Processes 


Figure  2-6.  Implementation  Phases  for  the  DA  Program 


Continued  on  next  page 
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2.5.  Program  Implementation,  Continued 


Approval  The  approval  phase  establishes  the  foundation  for  the  fleet  logistics  DA  program 

by  providing  the  authorization,  initial  funding,  processes,  and  infrastructure  to 
move  the  program  forward.  The  approval  phase  includes  following  types  of 
actions: 

•  Complete  the  selection  and/or  development  of  DA  standards,  processes,  and 
requirements. 

•  Allocate,  define,  and  fix  responsibility  for  an  agreed  set  of  information 
classes. 

•  Refine  requirements  and  plan  implementation  for  the  fleet  logistics  metadata 
repository. 

•  Approve  the  fleet  logistics  DA  program  and  publish  the  DAPAP  manual. 

•  Develop,  approve,  and  fund  a  training  plan  to  support  the  DA  program. 

•  Approve  and  fund  the  repository  platform  (equipment,  software, 
communications,  and  support). 

•  Tailor  and  submit  DIDs  and  RFP  language  that  support  the  metadata 
deliverables  and  review  process. 

•  Develop  training  materials  to  support  the  DAPAP  processes,  repository, 
acquisition  documents,  standards,  and  related  DA  activities. 

•  Make  the  approved  DA-related  roles  and  responsibilities  official. 

•  Develop  and  submit  the  initial  DA  budget. 

In  a  two-year  implementation  cycle,  for  example,  these  actions  would  be 
completed  by  the  third  quarter  of  the  first  fiscal  year. 


Funding  &  The  second  phase  launches  implementation  of  the  DA  program.  It  prepares  the 
Programming  program  for  deployment  into  the  fleet  logistics  community.  Launching  the  DA 
program  requires  the  following  actions: 

•  Allocate  the  approved  responsibilities  to  organizations  and  individuals. 

•  Recruit  one  principal  data  steward  (with  support  as-needed)  for  each 
information  class. 

•  Initiate  the  fleet  logistics  enterprise  data  model. 

•  Approve  and  produce  DA  training  materials. 

•  Approve  and  program  the  DA  deployment  budget. 

•  Staff  and  equip  the  DA  office. 

•  Implement  DA  operations  and  develop  the  operation  phase  budget. 

•  Procure  the  repository  equipment,  software,  communications,  and  support. 
In  a  two-year  implementation  cycle,  these  actions  should  be  completed  by  the 
first  quarter  of  the  second  fiscal  year. 
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2.5.  Program  Implementation,  continued 


Deployment  The  deployment  phase  provides  to  the  fleet  logistics  community  the  information, 
support,  processes,  and  skills  to  execute  an  effective  DA  program.  Deploying  the 
DA  program  requires  the  following  actions: 

•  Train  data  stewards  and  DA  staff 

•  Establish  liaison  with  DoD,  industry,  and  standards  organizations 

•  Include  DA-tailored  DIDs  in  fleet  logistics  IS  procurements 

•  Model  the  primary  fleet  logistics  business  processes 

•  Inventory  which  information  systems  use  which  data  items 

•  Populate  an  initial  enterprise  data  model 

•  Recruit  subject  matter  experts 

In  a  two-year  implementation  cycle,  these  actions  should  be  completed  by  the 
third  quarter  of  the  second  fiscal  year. 


Operation  The  start  of  the  operation  phase  marks  the  start  of  "actual"  data  administration 
and  the  completion  of  preparatory  work.  Operation  includes  execution  of  the 
processes  described  in  this  manual.  Note  that  operation  involves  much  more  than 
a  DA  office.  The  DA  function  provides  support  for  users,  developers,  data 
stewards,  system  administrators,  planners,  and  others  to  do  their  respective  parts 
to  achieve  enterprise-wide  sharable  data.  Operating  the  DA  program  requires  the 
following  actions: 

•  Coordinate  data  standards  with  CG,  other  Government  agencies,  industry, 
and  standards  organizations 

•  Participate  in  strategic  data  planning 

•  Provide  outreach  and  technical  support  to  users  and  developers 

•  Provide  training  to  DA  and  acquisition  staff,  data  stewards,  and  developers 

•  Review  metadata  change  requests 

•  Review  metadata  and  deliverable  documents 

•  Review  and  register  standard  systems 

•  Refine  entity  and  data  element  definitions  through  the  data  stewards  and  their 
respective  user  organizations 

•  Expand  and  refine  the  enterprise  logical  data  model 

•  Provide  repository  services 

•  Monitor  the  quality  of  data  values  in  the  enterprise  data  resource 

•  Improve  DA  processes 

To  complete  a  two-year  implementation  cycle,  these  actions  should  be  started 
before  the  end  of  the  second  fiscal  year. 
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SECTION  3 


SUPPORT  DEVELOPMENT  AND  INTEGRATION 
OF  DATA  MODELS 


3.1.  Overview 


Purpose  This  section  provides  the  concepts,  guidance,  and  procedures  to; 

•  Develop  a  conceptual  or  logical  data  model  by  developers,  system 
maintainers,  data  stewards,  and  process  improvement  teams 

•  Submit  the  model  to  the  fleet  logistics  Data  Administrator  (DA)  for 
review 

•  Review  it  and  resolve  any  discrepancies  with  current  metadata  standards 

•  Integrate  it  into  the  fleet  logistics  data  model  and  the  fleet  logistics 
metadata  repository 

•  Maintain  the  integrated  logistics  data  model  configuration 

•  Generate  specific  data  model  views  and  reports  for  application 
developers 

•  Coordinate  and  improve  the  data  model  development/integration  process. 

These  procedures  are  used  to: 

•  Describe  the  data  and  relationships  in  a  previously  undocumented 
processes,  and  to  update  or  standardize  metadata  in  documented 
processes 

•  Determine  the  subset  (view)  of  the  fleet  logistics  data  model  to  download 
from  the  repository,  as  a  starting  point  for  the  application  data  model 

•  Design  a  new  or  newly  standardized  information  system 

•  Upgrade  and  standardize  an  existing  system 

•  Identify  and  transmit  an  application  data  model  or  metadata  change 
request  to  DA  for  review 

•  Define  the  mapping  of  data  from  a  legacy  system  to  the  fleet  logistics 
standard  information  resource. 


In  this  Section  This  section  covers  the  following  data  modeling  topics  and  procedures: 


Topic 

Section 

Overview  of  Process  and  Responsibilities 

3.1 

Data  Modeling  Concepts 

3.2 

Develop  and  Submit  Data  Model  (developer/maintainer,  data 
steward.  Quality  Action  Team) 

3.3 

Receive  and  Evaluate  Data  Model  (DA) 

3.4 

Submit  Changes  to  Data  Models 

3.5 

Maintain  Configuration  of  Data  Models 

3.6 

Generate  Data  Models  from  the  Repository 

3.7 

Coordinate  Data  Model  Development  and  Integration 

3.8 

Improve  the  Data  Model  Development  and  Integration  Process 

3.9 

Continued  on  next  page 
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3.1.  Overview,  Continued 


Procedure 

Cross- 

Reference 


To  describe  the  process  of  developing  application  data  models  in  accordance 
with  the  enterprise  logical  data  model,  this  section  provides  the  following  types 
of  information: 


Topic  /  Procedure 

Audience 

Refer  to  Subsection 

Introduction  to  data  modeling 
concepts  and  conventions  of  the 
DoD-compliant  methodology 

All  readers 

Data  Modeling  Concepts 
(Section  3.2  and 

Appendix  A) 

Develop  a  conceptual  or  logical 
data  model  and  submit  it  to  DA  for 
review  and  standardization 

Developers  and 
system 
maintainers: 
analyst/modeler, 
system  designer 

Develop  and  Submit  Data 
Model  (Section  3.3) 

Validate  data  model  with  users 

All  readers 

Receive  data  model  from  the 
system  design  team  and  review  for 
standards  conformance 

Fleet  logistics 

Data 

Administrator 

Receive  and  Evaluate  Data 
Model  (Section  3.4) 

Prepare  and  submit  changes  to  a 
previously  approved  data  model 

Developer 

Submit  Metadata  Changes 
(Section  3.5) 

Integrate  submitted  data  model  into 
the  fleet  logistics  data  model 
resolving  metadata  differences 

Fleet  logistics 

Data  Admin.,, 
Stewards 

Integrate  fleet  logistics 

Data  Model 
(section  3.4  and  3.6) 

Make  changes  to  metadata  that  has 
been  previously  submitted, 
checked,  and  integrated 

Fleet  logistics 

Data 

Administrator 

Maintain  Configuration  of 
Data  Models  (section  3.6) 

Generate  specialized  data  models, 
user  views,  where-used  reports,  and 
other  subset  metadata  from  the 
repository 

Fleet  logistics 

Data  Admin., 

Stewards, 

Developers 

Generate  Data  Models 
from  the  Repository 
(section  3.7) 

Initiate  and  coordinate  the  data 
modeling  and  integration  process 
during  system  development 

Fleet  logistics 

Data 

Administrator 

Coordinate  Data  Model 
Development  and 

Integration  (Section  3.8) 

Capture,  document,  and  submit 
issues  and  improvements  to  the 
data  modeling  process 

Fleet  logistics 

Data  Admin., 
Stewards 

Improve  the  Data  Model 
Development  and 

Integration  Process  (3.9) 

Continued  on  next  page 
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Support  Development  and  integration  of  Data  Models 


Specific  Data 
Modeling 
Responsibili¬ 
ties 


An  effective  data  administration  program  has  four  key  starting  points:  strategic  data 
planning  at  the  enterprise  level,  a  proactive  data  administration  program  that 
maintains  a  current  and  valid  metadata  repository,  an  active  data  stewardship 
program,  and  commitment  by  the  application  developers  to  create  a  standard  system 
and  to  use  the  enterprise  data  resource.  The  following  table  summarizes  the 
responsibilities  that  are  necessary  to  develop,  standardize,  and  use  data  models. 


Role 

Responsibility 

Description 

Section 

Data  User 
Organizations 

Strategic  Data 

Planning 

Establish  requirements  that 
ensure  the  new  or  upgraded 
system’s  data  is  sharable. 

3.3, 5.2, 
5.3,  8.1, 
8.7, 

Data  User 
Organizations 

System  Acceptance 

Accept  new  and  upgraded 
systems  only  after  transparent 
data  sharing  is  demonstrated. 

5.2, 5.3, 
8.6,  8.8 

Data 

Administrator 

Standards  for 
Deliverables  and 
Acceptance 

Ensure  that  information 
system  solicitations, 
statements  of  work,  CDRL 
items,  and  DIDs  provide  for 
data  standards  compliance  and 
acceptance  testing,  and 
adequate  metadata 
deliverables. 

3.3. 4.3, 

5.2. 5.3, 

7.2. 8.3, 

11.3,  11.4 

Acquisition 

System  Acquisition 

Include  contractual  language 
and  CDRL  items  that  ensure 
transparently  shareable  data. 

8.6, 11.4 

Developer, 

System 

Maintainer 

Design 

Build-in  the  enterprise  data 
model  and  other  org.  data 
sharing  requirements  into 
preliminary  design. 

3.3, 3.7, 

8.1,8.10, 

8.11, 

Developer 

Data  Modeling 

Obtain  user  access  to  the  fleet 
logistics  metadata  repository. 

6 

Developer, 

System 

Maintainer 

Data  Modeling 

During  analysis,  identify  data 
items  that  correspond  to 
existing  standard  data 
elements.  Download  subset 
data  model  from  repository. 
Define  new  data  elements  for 
only  the  few  truly  unique  data 
items. 

3.3, 4.2, 
4.3,  8.6, 
11.3 

Developer, 

System 

Maintainer 

Change  Control  of 
Application  Metadata 

Keep  the  application’s  data 
model  concurrent  with  the 
physical  design,  and  submit 
all  metadata  changes  to  DA. 

3.6, 4.5, 

7.x 

Continued  on  next  page 
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3.1.  Overview,  Continued 


Specific  Data  Modeling  Responsibilities  (Continued) 


Data  Admin. 

Receive  &  Evaluate 
Data  Model 

Review  conceptual,  logical, 
and  attributed  data  models  and 
metadata  documents  at 
appropriate  phases. 

Investigate  &  approve  or 
negotiate  requests. 

3.4,  4.3, 

4.4,  8.1, 
8.6,  8.9, 
11.3 

Developer  or 
maintainer 

Prepare  Metadata  for 
Joint  User-Developer 
Technical  Reviews 

Complete  preliminary  logical 
data  model  and/or  data 
conversion  plan,  identify  data 
sharing  requirements  and 
interfaces,  and  describe  key 
data  items  for  user  validation. 

11.3, 11.6 

Data  Admin. 

Validate  Metadata  for 
Technical  Reviews 

Review  preliminary  logical 
data  model;  identify  standard 
and  unique  data  items; 

11.3 

Data  Admin. 

Facilitate  Metadata 
Portion  of  Technical 
Reviews 

Interpret  the  implications  of 
the  data  model  to  technical 
reviewers,  and  obtain 
clarification  of  business 
processes  and  data 
requirements. 

11.3, 11.4 

Data  Admin. 

Identify  Data  Planning 
Issues  for  Management 
Reviews 

Identify  need  for  management 
decisions  regarding  strategic 
data  planning,  data  sharing, 
interfaces,  standardization, 
processes,  and  schedules. 

11.3 

Data  Admin. 

Support  data 
standardization  work 

Provide  standard  metadata  and 
technical  support  to 
developers  &  maintainers. 

3.8,  8.3, 
8.4,  8.5, 

Data  Admin 

Control  Changes  to 
Standard  Metadata 

Review  and  track  change 
requests;  maintain  enterprise 
metadata  repository. 

Data  Admin 

Coordinate  Metadata 
with  CG  Data  Admin 

Coordinate  definition  of  new 
or  changed  metadata  with  CG 
Data  Administrator. 

Data  Admin 

Accept  Model  and 
Register  Standard 
Systems 

After  acceptance,  register 
standard  systems  and 
authorize  sharing  of  FL  data. 

8.8 

Continued  on  next  page 
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Specific  Data  Modeling  Responsibilities  (Continued) 


Data  Stewards 

Understand  Uses  of 

Data 

For  the  information  class(es) 
assigned  for  stewardship, 
identify  all  uses  of  data, 
systems  where  it  is  used,  data 
flow,  and  interfaces. 

9.2, 9.3 

Data  Stewards 

Review  Change 
Requests 

Review  data  entity  and 
element  change  requests  for 
usefulness,  standards 
compliance,  and  impact  on 
other  systems. 

3.4, 4.4 

Data  Stewards 

Ensure  Data  Quality 

Monitor  data  integrity, 
security,  synchronization,  etc. 

8.13, 9.3 

Data  Admin. 

Ensure  Preservation  of 
Metadata 

Ensure  responsibility  for 
developer  and  DA  backup  of 
data  models  and  other 
metadata. 

10.5 

Data  Admin  & 
Stewards 

Improve  DA  Processes 

Improve  DA  processes  by 
monitoring  data  quality,  IRM 
processes,  data  customers  & 
suppliers. 

2.5,  3.9, 
4.6, 8.15, 
11.6 

DA  Function 
on 

Development 

Teams 


Each  organization  that  is  authorized  to  create  or  modify  an  information  system  must 
provide  a  data  administration  function.  Typically  this  function  is  provided  as  part  of 
system  analysis.  However,  on  a  specific  team  the  expertise  might  reside  in  the 
database  design,  quality  assurance,  or  configuration  management  functions.  Larger 
projects  require  a  separate  data  administrator. 


A  development  or  software  maintenance  team’s  data  administrator  provides  the 
following  critical  services: 

•  Point  of  contact  for  fleet  logistics  DA 

•  Advocate  for  transparent  data  sharing 

•  Author  of  metadata-related  segments  of  deliverable  documents 

•  Contributor  to  interface  design 

•  Participant  in  analysis  of  data  requirements  and  data  flow 

•  Submitter  of  data  models  and  metadata  change  requests 


The  designated  data  administrator  should  contact  the  fleet  logistics  data 
administrator  as  soon  as  possible  after  appointment  to  obtain  necessary  information, 
a  user  account  on  the  metadata  repository  system,  and  training. 
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3.2.  Data 


Purpose  and 
Objectives  of 
Data  Models 


Data 

Modeling 

Technique 


DoD- 

Compliant 

Methodology 

Conventions 


Modeling  Concepts 


A  data  model  graphically  depicts  "things"  (entities  or  objects)  of  principal 
concern  to  an  organization,  and  the  ways  they  relate  to  each  other  statically  (that 
is,  the  permanent  relationships  between  the  things,  not  the  changes  applied  to 
their  values  or  the  processes  through  which  they  flow). 

A  data  model  is  used  first  to  describe  the  data  the  organization  must  track,  and 
then  to  provide  a  common  basis  for  interpretation  and  integration  of  the  data 
throughout  the  life  cycle  of  one  or  multiple  information  systems.  It  ensures  that 
data  is  interpreted  consistently  across  functional,  organizational,  and  information 
system  boundaries.  Ultimately,  data  models  are  used  to  develop  database  schema 
during  system  design  and  construction. 

Accurate  data  and  process  models  are  used  to  plan,  prioritize,  analyze,  design, 
and  construct  information  systems.  These  models  are  useful  not  only  for  original 
design,  but  also  for  re-use,  migration,  and  maintenance  of  data.  Data  models  are 
developed  alternately  and  iteratively  with  process  models,  successively  refining 
each  in  greater  detail  until  they  accurately  represent  the  organization  to  the 
needed  level  of  detail.  Data  modeling  is  the  method  and  technique  for  defining 
and  assessing  the  business  area  data  requirements  that  will  be  supported  in 
application  systems,  and  is  therefore  the  basis  for  effective  data  administration. 

At  the  requirements  analysis  phase  of  the  system  development  life  cycle,  the 
application's  attributed  data  model  is  reviewed  for  consistency  to  the  system 
process  model  requirements  and  for  completeness  of  definitions  of  all  data 
entities  and  their  relationships.  Submittals  of  standard  data  element  requests  are 
evaluated  using  the  application's  approved  data  model  for  reference. 


A  data  modeling  technique,  also  known  as  an  entity  relationship  (E-R)  or  entity- 
relationship-attribute  (E-R-A)  diagrams  is  the  principal  technique  used  to  identify 
and  verify  the  organization's  data.  A  data  model  diagram  depicts  an 
organization's  objects  of  interest  (entities),  and  the  relationships  that  exist 
between  those  entities.  It  also  reflects  the  business  rules  of  the  organization.  At 
its  lowest  level  of  detail,  it  also  tracks  types  of  data  kept  about  each  object. 


Fleet  logistic  functions  need  to  interface  with  DoD  systems  and  with  commercial 
systems  that  deal  with  other  Government  agencies.  So,  DoD-compliant 
computer-aided  software  engineering  (CASE)  methodology  conventions  are  the 
recommended  minimum  standards  for  development  and  depiction  of  E-R  data 
models  for  fleet  logistics  applications.  DoD  methodology  includes  terminology 
for  E-R  concepts,  notation  for  E-R  diagrams,  and  query  capabilities  for  working 
with  data  models.  A  summary  of  this  methodology's  conventions  is  provided  in 
following  paragraphs  and  in  Appendix  A. 


Continued  on  next  page 
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3.2.  Data  Modeling  Concepts,  continued 


Components  Data  models  have  three  components: 

and  Basic 

Concepts  of  •  Diagrams:  A  diagram  or  set  of  diagrams  depicting  the  three  basic  data 

Data  Models  modeling  concepts  of:  entities  of  the  organization  needs  to  track, 

relationships  between  these  entities,  and  attributes  of  the  entities. 

•  Glossary:  A  glossary  (often  called  data  dictionary)  containing  a  complete 
and  unambiguous  definition  of  each  entity,  relationship,  and  attribute  in  the 
data  model. 

•  Business  rules:  A  written  statement  of  the  business  rules  depicted  in  each 
relationship  of  the  model. 


Data  Modeling  Data  modeling  conventions  for  identifying,  categorizing,  defining,  and 
Conventions  integrating  in  data  models  the  basic  concepts  of  entities,  relationships,  and 
attributes  are  described  in  Section  3.3,  Develop  and  Submit  Data  Model. 

These  data  modeling  conventions  are  based  on  the  DoD-compliant  methodology 
conventions  refined  from  the  classical  E-R  modeling  technique.  Similar 
conventions  exist  for  most  other  versions  of  E-R  modeling  techniques.  Using 
this  methodology,  data  modeling  concepts,  conventions,  and  terminology 
provides  a  common  language  among  development  teams,  who  may  be  using 
different  analysis/modeling  techniques  and  CASE  tools.  However,  this  document 
does  not  impose  the  graphical  notation  diagramming  conventions  because  those 
are  dependent  on  a  particular  CASE  tool  convention  or  software  product. 

It  is  the  responsibility  of  the  development  or  maintenance  team  to  translate  any 
internal  terminology  to  the  equivalent  DoD-compliant  CASE  methodology 
language  before  submitting  deliverables  or  sharing  information  with  other  teams. 


Additional  Appendix  A  provides  a  summary  of  data  modeling  and  examples  of  the  concepts 

Explanation  used  in  the  following  procedures.  Further  detail  is  available  from  the  references 

cited  in  Section  1. 


Support  Development  and  Integration  of  Data  Models 


3.3.  Develop  and  Submit  Data  Model 


Purpose  This  section  describes  the  preparation  of  conceptual  and  logical  data  models  for 

an  application,  and  presents  a  recommended  development  process.  This  process 
consists  of  five  parts; 

•  Develop  conceptual  data  model 

•  Develop  key-based  logical  data  model 

•  Submit  logical  data  model 

•  Develop  attributed  data  model 

•  Submit  attributed  data  model 

Section  11  shows  where  these  processes  fit  into  the  typical  system  development 
phases. 


For  a  new  or  redesigned  information  system,  the  development  team  charged  with 
application  design  is  responsible  for  performing  the  tasks  described  in  this 
subsection.  Data  models  are  also  developed  by  data  stewards  to  describe  a 
business  process,  or  by  users  who  require  a  specialized  view  of  the  data.  The 
individual  who  takes  the  lead  in  this  data  modeling  effort  should  notify  fleet 
logistics  data  administration  (DA),  and  will  serve  as  the  point  of  contact  for  data 
administration  issues.  This  individual  should  obtain  a  user  account  on  the  fleet 
logistics  metadata  repository  system.  Although  the  approved  attributed  data 
model  is  the  critical  deliverable  product,  the  developer  is  encouraged  to  work 
with  fleet  logistics  DA  at  each  stage  of  data  model  development,  to  ensure 
compatibility  of  the  application's  data  definitions,  and  to  expedite  acceptance  of 
the  Database  Description  Document  (DBDD),  Interface  Description  Document(s) 
(IDD),  and  data  model.  Refer  to  Section  11,  Data  Life  Cycle  Methodologies  for 
specific  metadata  deliverables  associated  with  development  milestones. 


Responsi¬ 

bility 


Metadata  and  Design  reviews,  especially  user/developer  joint  technical  reviews  held  early  in  the 
Design  design  phase,  are  valuable  forums  for  validating  and  resolving  data  issues. 

Reviews  Management  reviews  are  an  appropriate  forum  for  presenting  issues  such  as 

standards,  data  re-use,  and  data  quality.  These  review  forums  cannot,  however,  take 
the  place  of  the  consistent  data  model  and  data  element  normalization  process 
described  in  Sections  3  and  4, 

As  noted  in  Section  11,  the  system  developer  or  maintainer  should  transmit  the 
logical  data  model  after  resolution  of  comments  from  the  preliminary  design  review 
(PDR)  with  the  System  Specification  (SSS),  preliminary  DBDD  and  preliminary 
IDD  at  the  end  of  the  system  design  or  high-level  design  phase.  The  developer  or 
maintainer  should  transmit  the  attributed  data  model  as  part  of  the  package  (with 
SSS  and  System  Requirements  Specification,  DBDD,  and  IDDs)  at  the  end  of  the 
detailed  design  phase.  DA  accepts  the  application  data  model  when  all  entities, 
relationships,  and  data  elements  are  congruent  with  the  fleet  logistics  enterprise  data 
model. 


Continued  on  next  page 
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3.3. 


Develop  and  Submit  Data  Model,  continued 


Levels  of  There  are  three  levels  of  refinement  for  a  data  model,  each  more  detailed: 

Data  Models 

Entity-relationship  conceptual  data  model:  At  this  level,  only  the  entities  and 
relationships  are  shown.  This  model  is  generally  used  to  show  information  about 
a  broad  subject  area  with  limited  depth  of  detail.  This  model  may  show  non¬ 
specific  relationships  as  well  as  specific  ones.  At  this  stage,  the  design  team 
should  investigate  the  metadata  repository  to  match  application  data  requirements 
with  standard  definitions,  for  as  many  entities  as  possible.  Refer  to  Section  6, 
Implement  Metadata  Repository,  for  use  of  the  metadata  repository. 

Key-based  logical  data  model:  In  this  model,  keys  for  each  entity  are  designated 
and  shown.  All  non-specific  relationships  should  have  been  resolved 
(normalized)  at  this  point.  Only  specific  relationships  appear  in  this  level  model, 
identified  with  primary  and  foreign  keys.  At  this  stage,  the  design  team  should 
have  incorporated  all  possible  standard  entity  definitions,  and  identified  unique 
entities  for  submittal  as  candidates. 


Fully  attributed  logical  data  model:  In  this  model,  all  attributes  of  each  entity 
are  shown.  This  is  a  highly  detailed  but  narrowly  scoped  model  that  can  be  used 
for  system  construction  and  implementation.  This  model  should  reuse  standard 
data  elements  as  much  as  possible.  All  entity  standardization  issues  should  be 
resolved  with  the  Data  Administrator  before  approval.  Approval  of  the  fully 
attributed  model  is  required  before  development  can  proceed. 


Data  Model  Development  of  a  conceptual  and  logical  data  model  for  an  application  is 

Development  generally  a  three-stage  process  with  increasing  levels  of  detail  included  to 
Process  support  the  three  levels  of  data  model  refinement. 

Note  that  this  process  requires  identification  of  data  using  standard  entity  and 
element  definitions  first,  then  validation  of  new  definitions  for  definitions  not 
found  in  the  standard  set.  This  sequence  is  required  for  development  or  upgrade 
to  a  fleet  logistics  standard  system. 

The  acceptance  criteria  for  deliverable  data  models  are  provided  in  Section  8, 
Ensure  Data  Quality. 


Continued  on  next  page 
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3.3.  Develop  and  Submit  Data  Model,  continued 


Develop  This  procedure  results  in  the  initial  ER  diagram,  based  on  standard  metadata. 

Conceptual  Use  this  information  for  preliminary  design  documentation.  Determine  the 
Data  Model  entities  and  the  relationships  between  them  reusing  standardized  definitions  from 
the  fleet  logistics  corporate/enterprise  data  model,  using  the  following  procedure: 


Step 

Action 

1 

Determine  Scope: 

Establish  the  scope  (breadth)  and  level  (depth)  of  the  data  modeling 
effort  for  this  application.  Use  the  business  process/activity  model 
(DoD  methodology  or  equivalent)  as  a  basis  to  establish  this  scope. 

2 

Define  View  and  Import  Standard  Metadata: 

Define  the  view  of  the  data  required  for  the  purpose  and  scope  of  the 
model,  and  download  a  corresponding  set  of  metadata  from  the  fleet 
logistics  DA  repository.  Load  these  entities  and  attributes  into  the 
modeling  tool  as  a  starting  point. 

3 

Collect  Source  Information: 

Use  process  model,  high-level  data  architecture,  requirements 
documents,  analyses,  functional  procedures,  training  materials  and 
other  available  information.  Research  all  information,  interfaces,  and 
processes  within  the  scope  of  the  application.  Identify  all  data  items 
that  are  created,  used,  changed,  or  deleted. 

4 

Match  Source  Data  with  Standard  Metadata: 

Match  data  items  with  standard  entities  and  data  elements  as  much  as 
possible.  When  small  discrepancies  are  encountered,  consult  the 
appropriate  data  steward  to  validate  the  uniqueness  of  the  local  data. 

Most  data  items  should  map  to  standard  entities  and  data  elements. 

5 

Determine  Entities  for  Unique  Data  Items: 

For  any  data  items  that  cannot  be  matched  with  standard  entities  and 
elements,  define  new  metadata.  Define  candidate  primary  entities. 

Test  that  each  is  uniquely  identifiable.  Validate  the  uniqueness  of 
each  apparently  unique  entity  and  element  with  the  appropriate  data 
steward. 

Continued  on  next  page 
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3.3. 


Develop  and  Submit  Data  Model,  Continued 


Develop  Conceptual  Data  Model  (continued) 


6 

Determine  Relationships: 

Model  all  connection  relationships,  name  and  define  each,  and  document 
each  with  business  rules.  Note  differences  from  the  relationships  that 
were  provided  with  the  standard  metadata.  Validate  the  differences  with 
the  appropriate  data  steward(s). 

7 

Prepare  ER  Diagram: 

Draw  the  entity  relationship  diagram  for  the  application's  view,  using  the 
validated  metadata  developed  in  the  previous  steps. 

8 

Validate  and  Integrate  Diagram: 

Use  an  extended,  expert  team  to  validate  the  model  for  accuracy  and 
completeness.  Integrate  multiple  views.  Using  the  fleet  logistics  metadata 
repository,  match  each  candidate  entity  to  the  closest  standard  entity,  and 
reconcile  in  favor  of  standard.  This  version  of  the  model  can  be  used  in 
functional  requirements  documentation. 

Developer 
Access  to 
Standard 
Metadata 


The  fleet  logistics  data  administrator  will  provide  technical  support  to  load  fleet 
logistics  standard  metadata  as  a  starting  point  for  a  new  or  revised  application  data 
model.  The  project  data  administrator  should  contact  the  fleet  logistics  DA  for 
additional  information. 

Online  access  to  the  fleet  logistics  metadata  repository  should  be  requested  from  the 
Fleet  Logistics  Center  IRM  Division.  Include  in  the  request  the  name  of  each 
requested  user,  with  organization,  job  title,  email  address,  and  location. 

Online  access  to  the  Coast  Guard  Data  Dictionary  System  (DADDS)  should  be 
requested  from  the  Coast  Guard  Data  Administrator  (G-TTC-3). 


Continued  on  next  page 
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3.3.  Develop  and  Submit  Data  Model,  continued 


Develop  Key- 
Based  Logical 
Data  Model 


This  is  the  second,  refining  and  validating  phase  of  data  model  development. 
This  step  ends  with  submittal  of  the  logical  data  model  and  draft  DBDD.  Add 
detail  to  entities  and  relationships,  and  determine  a  unique  identifier  and 
definition  for  each  entity  that  eliminates  redundancies,  nonspecific  relationships, 
and  nonstandard  definitions,  as  follows: 


1 

Resolve  all  nonspecific  relationships: 

Eliminate  many-to-many  relationships  by  introducing  associative  entities; 
define/document  them.  Define  new  relationships  between  the  new 
associative  entity  and  the  entities  associated  by  the  old  nonspecific 
relationship. 

2 

Identify  candidate  keys: 

For  each  independent  entity,  list  all  attributes  (or  sets  of  attributes)  that 
could  serve  to  uniquely  identify  instances  of  the  entity. 

3 

Select  primary  key: 

For  each  entity,  select  from  the  candidate  keys  the  best  candidate  and 
designate  it  as  the  primary  key. 

4 

Migrate  foreign  keys: 

After  choosing  primary  keys,  "migrate"  these  keys  through  relationships  to 
become  foreign  keys  in  other  entities.  Primary  keys  in  parent  entities 
migrate  "downward"  to  become  foreign  keys  in  child  entities.  Designate 
primary  keys  for  dependent  entities. 

5 

Expand  category  hierarchies: 

Expand  category  hierarchies  and  establish  category  relationships  for  subtype 
entities. 

6 

Refine  and  revalidate  the  model  to  application  and  to  standard: 

Once  detail  has  been  added,  reevaluate  the  model  to  ensure  it  is  still 
syntactically  and  semantically  correct.  Refine  the  E-R  diagrams  and  entity 
definitions.  Indicate  cardinalities  for  all  relationships. 

7 

Integrate  key-based  model  into  application  data  model: 

Submit  this  validated  logical  model  to  fleet  logistics  Data  Administration 
for  evaluation.  Submit  a  copy  of  the  validated  key-based  model  and  the 
revised  application  model  to  DA  repository  configuration  management. 

This  model  version  can  be  used  in  detailed  requirements  documentation, 
including  the  preliminary  versions  of  the  DBDD  and  IDD 

8 

Develop  and  standardize  primary  key  data  elements: 

Define  the  primary  key  data  elements  as  standard  data  elements. 

NOTE:  Primary  keys  must  be  standard  data  elements.  For  primary  keys  that  are  not 
be  defined  as  standard  data  elements,  prepare  a  standard  data  element  candidate 
request  and  submit  to  fleet  logistics  Data  Administration. 

9 

Submit  Validated  Logical  Data  Model: 

Prepare  and  submit  the  ER  diagram  along  with  the  draft  DBDD.  For  a 
development  project,  submit  through  the  program  office.  For  a  user- 
developed  application,  submit  these  documents  to  DA  for  review. 

Continued  on  next  page 
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3.3.  Develop  and  Submit  Data  Model,  continued 


Develop  Once  the  logical  data  model  and  preliminary  DBDD  are  approved,  add  the  next 

Attributed  level  of  detail,  the  attributes  for  each  entity.  Again,  use  standard  attribute  names 

Data  Model  and  definitions  first,  and  create  new  ones  for  validated  unique  requirements  only. 

Complete  the  task  of  identifying  all  attributes  for  entities  and  defining  metadata 
for  each  attribute/data  element,  as  follows: 


Step 

Action 

1 

Determine  non-key  attributes: 

Identify  all  non-key  entity  attributes.  Record  any  known  information 
about  each,  but  emphasize  identification. 

2 

Identify  category  discriminators: 

Designate  attributes  that  discriminate  among  instances  of  category 
entities. 

3 

Integrate  into  the  application  data  model: 

As  with  the  key-based  model,  integrate  the  model  back  into  the 
application  model.  Submit  a  copy  of  the  key-based  model  and  the  updated 
application  model  to  Configuration  Management. 

4 

Develop  standard  data  elements: 

Once  a  model  is  fully  attributed,  each  attribute  must  be  rigorously  defined 
as  a  data  element  (refer  to  Section  4,  Standardize  Data  Elements).  This 
version  of  the  model  can  be  used  in  the  CSCI  software  requirements 
milestone  review,  and  as  a  basis  for  the  physical  database  design. 

5 

Submit  for  Acceptance  and  Integration: 

Prepare  and  submit  the  attributed  data  model  for  acceptance  by  the  fleet 

logistics  DA: 

1 .  Obtain  development  team  management  release,  typically  through  a 
Quality  Assurance  a  group. 

2.  Prepare  transmittal  forms  and  associated  documentation. 

3.  Transmit  through  the  program  manager  to  DA.  The  preferred  means 
of  transmittal  will  be  specified  by  DA. 

4.  Correct  discrepancies  when  notified,  and  resubmit  the  corrected 
model. 

5.  A^^en  accepted,  use  the  attributed  data  model  as  the  basis  for 
physical  database  and  application  design. 

6.  During  software  development,  submit  revisions  as  necessary.. 

6 

Submit  Attributed  Data  Model  and  DBDD: 

Prepare  and  transmit  the  attributed  data  model  along  with  the  final 

DBDD  and  accompanying  IDDs.  For  a  development  project,  submit 
through  the  program  office.  For  a  user-developed  application,  provide 
design  and  database  and  interface  description  documents  to  DA  for 
review. 

Continued  on  next  page 
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3.3.  Develop  and  Submit  Data  Model,  continued 


Data  Model  The  proposal  package  consists  of  the  ER  diagram,  electronic  version  of  the 
Submittal  model  in  the  prescribed  format,  and  related  hardcopy  documentation  (such  as 
Package  DBDD).  The  package  should  be  of  a  size  and  complexity  that  the  proposed  data 
model/subset  can  be  understood  and  placed  in  context  with  other  models  for 
related  functions  or  entities.  DA  will  specify  the  appropriate  means  for 
transmittal. 

When  a  large  model  is  being  used  for  a  proposal,  a  number  of  sets  of  proposal 
packages,  each  based  on  a  partition  of  manageable  size,  should  be  prepared  in 
accordance  with  the  guidelines  in  this  section.  The  partitions  between  the  set  of 
proposal  packages  do  not  need  to  contain  model  components  that  are  all  mutually 
exclusive.  An  entity  could  be  proposed  for  more  than  one  partition,  when  the 
entity  has  a  large  number  of  relationships  which  extend  across  the  boundaries  of 
the  larger  model. 


Identification  The  data  model  submittal  package  includes  the  following  components: 

of  Submittals 


Component 

Description 

1 

Application,  project,  or  function  name  and  identifier 

2 

Coast  Guard  sponsoring  organization  and  point  of  contact 

3 

Function  or  project  data  administrator  name  and  organization 

4 

Submittal  date 

5 

Version  number  and  date  of  the  subset  (view)  standard  metadata 
that  was  provided  to  initiate  this  modeling  process 

6 

Version  number  and  date  of  the  enterprise  data  model  the  proposal 
is  being  compared  to 

7 

Information  systems  within  the  CG  with  which  the  application 
shares  data 

8 

Information  systems  outside  the  CG  with  which  the  application 
shares  data 

9 

Information  system(s)  supported  by  the  E-R  Diagram 

10 

Model  component  count 

11 

CASE  Tool  (and  version)  used  to  generate  the  E-R  Diagram 

Utilize  Standard  definitions  are  available  in  the  fleet  logistics  metadata  repository.  As 

Standard  more  models  are  submitted,  the  number  and  variety  of  standard  entity  definitions 

Definitions  will  grow.  When  possible  utilize  a  standard  definition  rather  than  developing  a 
similar  unique  definition  or  subset.  Enterprise-wide  information  sharing  depends 
upon  compatible  data  across  systems.  This  principle  applies  both  to  the  fleet 
logistics  enterprise  and  the  CG  corporate  enterprise. 
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3.4.  Receive  and  Evaluate  Data  Model 


introduction  A  data  model  is  the  basis  for  understanding  and  defining  a  system’s  data 
requirements  through  the  concepts  of  data  entities  and  their  relationships. 

A  data  model  is  submitted  by  the  system’s  development  team  as  part  of  the 
Requirements  Analysis  and  Design  phase  for  the  system’s  functions.  This  data 
model  describes  the  data  entities  that  will  be  used  by  the  various  application 
systems  that  will  be  developed.  Review  and  acceptance  of  the  data  model  is 
critical  to  effective  analysis  of  data  administration  requirements. 

These  steps  show  how  fleet  logistics  DA  reviews  and  validates  a  submitted  data 
model,  and  then  integrates  the  data  model  into  the  fleet  logistics  metadata 
repository.  These  steps  are  important  because  the  repository  contains 
information  prescribing  how  data  is  used  in  all  fleet  logistics  operations. 

One  of  the  main  goals  of  the  fleet  logistics  DA  effort  is  to  provide  for 
organization-wide  use  of  the  data  resources  that  are  maintained  by  various  CG 
organizations  for  this  purpose.  Effective  use  depends  heavily  upon  matching  the 
definitions  and  names  of  similar  data  elements  throughout  the  system.  This 
matching  task  highlights  duplications  of  similar  data  entities.  It  prompts  for 
clarification  of  the  important  differences  between  distinctly  different  but  similar¬ 
appearing  entities.  Matching  the  definitions  and  interfaces  of  data  entities  is  the 
first  step  in  this  process. 


Responsi-  Performing  the  duties  described  in  this  subsection  is  the  responsibility  of  the  fleet 
bility  logistics  Data  Administrator  or  a  designee  of  the  Data  Administrator. 


Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  continued 


Data  Model 

Submittal 

Package 


The  proposal  package  is  used  to  propose  data  models  and/or  subsets  based  on  a 
tightly  integrated  function,  or  contained  in  a  single  subject  area,  as  a  candidate 
for  inclusion  into  the  standard  data  resource.  The  model  should  have  been 
prepared  in  accordance  with  the  procedure  provided  in  Section  3.3.  The  package 
should  be  of  a  size  and  complexity  that  the  proposed  data  model/subset  can  be 
understood  and  placed  in  context  with  Other  models  for  related  functions  or 
entities.  Quality  criteria  for  review  of  a  data  model  are  provided  in  Section  8. 


When  a  large  model  is  being  used  for  a  proposal,  a  number  of  sets  of  proposal 
packages,  each  based  on  a  partition  of  manageable  size,  should  be  prepared  in 
accordance  with  the  guidelines  in  this  section.  The  partitions  between  the  set  of 
proposal  packages  do  not  need  to  contain  model  components  that  are  all  mutually 
exclusive.  An  entity  could  be  proposed  for  more  than  one  partition,  when  the 
entity  has  a  large  number  of  relationships  which  extend  across  the  boundaries  of 
the  larger  model. 

System  developers  and  maintainers  should  use  this  checklist  to  prepare  the 
identifying  information  for  each  data  model  submittal  package.  Fleet  logistics 
DA  staff  will  use  this  list  to  check-in  each  submitted  package. 


Component 

Description 

1 

Application,  project,  or  function  name  and  identifier 

2 

Coast  Guard  sponsoring  organization  and  point  of  contact 

3 

Function  or  project  data  administrator  name  and  organization 

4 

Submittal  date 

5 

Version  number  and  date  of  the  subset  (view)  standard  metadata 
that  was  provided  to  initiate  this  modeling  process 

6 

Version  number  and  date  of  the  enterprise  data  model  the 
proposal  is  being  compared  to 

7 

Information  systems  within  the  CG  with  which  the  application 
shares  data 

8 

Information  systems  outside  the  CG  with  which  the  application 
shares  data 

9 

Information  system(s)  supported  by  the  E-R  Diagram 

10 

Model  component  count 

11 

CASE  Tool  (and  version)  used  to  generate  the  E-R  Diagram 

Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  continued 


Review  Fleet  logistics  DA  reviews  the  submitted  data  model  documentation  for 

Submitted  completeness  and  format,  using  the  following  procedure: 

Data  Modei 

(General)  _ _ 


Step 

Action 

1 

Log-in  package  as  received. 

-  Note  the  date  transmitted,  version  number  and  release  date,  title, 
number  of  separate  diagrams,  number  of  data  entities,  number  of 
relationships,  etc. 

2. 

Evaluate  the  submitted  model  against  related  existing  models. 

-  Identify  metadata  conflicts. 

-  Identify  potential  conflicts  among  the  other  models  in-process  that  have 
not  yet  been  integrated  into  the  standard  enterprise  model. 

3 

Check  scope. 

-  Does  this  data  model  represent  a  functional  business  area,  the  entire 
application  or  a  single  view? 

-  Does  this  data  model  correspond  to  the  previously  submitted  process 
model? 

-  If  the  data  model  does  not  correspond  to  the  process  model,  stop  review 
here  and  request  complete  model  from  developer  or  maintainer. 

4 

Check  the  entity  relationship  diagram. 

-  Does  the  model  meet  the  criteria  described  in  Section  8? 

-  Does  it  follow  DoD-compliant  CASE  methodology  notation? 

-  Are  all  entities  and  relationships  included  and  accurate? 

-  Are  all  relationships  normalized? 

-  Note  discrepancies  on  discrepancy  report. 

5 

Review  aggregate  entities. 

In  simplified  versions  of  the  model,  do  aggregate  entities  represent 
reasonable  abstractions  of  the  detailed  model? 

6 

Are  all  attributes  completely  identified  and  documented 

-  by  name,  definition,  and  type? 

-  Are  all  attributes  that  can  be  defined  using  standard  data  element 

definitions  so  defined? 

-  Are  all  nonstandard  attributes  necessary,  unique,  and  likely  candidates 
for  standard  data  elements? 

Disposition  of  When  fleet  logistics  DA  finds  that  a  data  model  package  is  improperly  or 
Incompiete  incompletely  identified  (see  checklist  above)  or  the  model  has  incomplete  or 

Submittals  inadequate  content  (see  procedure  above),  the  DA  will  return  the  package  (without 

evaluation  or  action)  to  the  developer  or  maintainer  for  correction  and  resubmittal. 


Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  continued 


Submit  and 
Review  Data 
Model 
(Entities) 


Developers  and  system  maintainers  will  prepare  and  fleet  logistics  DA  will 
review  the  entities  documented  in  this  data  model  for  completeness  and  format, 
using  criteria  in  Section  8  and  the  following  procedure: 


Step 

Action 

1 

Check  all  data  entities. 

-  Is  each  documented  completely  as  described  in  Section  3.2,  Develop 
and  Submit  Data  Model? 

-  Does  each  have  a  distinctive  and  appropriate  primary  key? 

-  Are  foreign  keys  migrated  through  the  indicated  relationships? 

-  Does  each  definition  match  a  standard  entity  definition? 

2 

Verify  the  information  class  for  each  entity. 

-  Do  all  entities  fit  into  the  current  standard  information  classes? 

-  Are  proponents  and  functional  experts  available  for  each? 

-  Do  new  information  classes  need  to  be  established,  definitions  adjusted, 
or  new  functional  experts  recruited? 

3 

Check  all  independent  entities. 

-  Is  each  properly  defined?  -  Is  each  uniquely  defined? 

4 

Check  all  dependent  entities. 

-  Is  the  unique  identification  of  its  instances  dependent  on  its  relationship 
with  one  or  more  other  entities? 

-  Is  the  dependence  documented  in  the  relationship? 

5 

Check  all  associative  entities. 

-  Does  each  replace  a  many-to-many  relationship? 

-  Is  the  dependency  in  both  directions  documented  in  the  business  rules 

and  in  the  relationship? 

6 

Check  all  Generic  and  Category  entities. 

-  Is  each  category  (subtype)  indicated  by  a  clear  and  appropriate 
discriminator  attribute? 

Coordination  For  each  entity  and  attribute  (data  element)  that  is  new  (not  part  of  the  fleet  logistics 

with  CG  standard  data  model),  the  fleet  logistics  DA  will  check  for  the  existence  of  a  similar. 

Metadata  usable  entity  or  attribute  in  the  CG  metadata  repository.  When  possible,  the  fleet 

logistics  DA  will  require  use  of  the  CG  entity  or  element  name  and  definition.  Use 
of  the  CG  entity  or  element  may  not  be  possible  if  the  proposed  new  entity’s  or 
element’s  characteristics  are  significantly  different  from  the  one  in  the  CG 
repository,  or  must  have  different  characteristics  in  order  to  share  data  with  other 
systems  or  organizations. 

When  the  fleet  logistics  DA  determines  that  a  new  entity  or  element  is  appropriate, 
the  DA  will  submit  the  new  entity  or  element  to  the  CG  DA  for  inclusion  in  the  CG 
metadata  repository. 


Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  Continued 


Submit  and 
Review  Data 
Model 

(Relationships) 


Developers  and  system  maintainers  will  prepare  and  fleet  logistics  DA  will 
review  the  relationships  documented  in  this  data  model  for  completeness  and 
format,  using  the  following  procedure: 


Step 

Action 

1 

Check  all  relationships. 

-  Is  each  properly  named  ENTITY- VERBPHRASE-ENTITY? 

-  Do  the  relationships  reflect  the  business  process? 

-  Do  the  relationships  indicate  the  best  use  of  information  resources? 

-  Is  the  business  rule  for  each  relationship  described? 

-  Are  parent-child  relationships  documented  adequately? 

-  Is  cardinality  indicated,  and  are  the  upper  and  lower  bounds  consistent 
with  the  business  rules? 

-  Is  each  relationship  necessary? 

-  Do  relationships  indicate  the  use  of  standard  data  resources  when 
available? 

-  Is  each  relationship  necessary  for  the  application? 

2 

Check  all  specific  relationships. 

-  Are  the  parent-child  relationships  documented  accurately? 

3 

Check  that  all  nonspecific  relationships  have  been  normalized  by 
introducing  an  associative  entity. 

4 

Check  that  recursive  relationships  are  documented  to  permit  following 
of  a  chain  of  relationships,  with  traceability  in  both  directions. 

5 

Check  that  structural  relationships  are  true  component-assembly 
relationships,  and  that  any  multiple  relationships  are  within  the 
capability  of  the  database  management  system  to  support. 

6 

Check  all  category  relationships. 

-  Is  a  category  discriminator  provided? 

-  Are  all  entity  type  hierarchies  appropriate  and  supported  by  the 

standard  data  definitions? 

Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  continued 


Validate 
Functional 
Attributes  and 
Business 
Rules 


After  issues  of  format,  completeness,  and  methodology  have  been  resolved  (or 
noted  as  a  discrepancy  for  later  resolution  by  the  developer  or  system 
maintainer),  the  functional  aspects  of  each  entity  must  be  validated  by  the 
appropriate  data  steward(s). 

The  fleet  logistics  DA  and  the  appropriate  data  stewards  will  assess  functional 
attributes  and  business  rules  using  the  following  process; 


Step 

Action 

Responsible 

Description 

1 

Assign 

Entities  to 
Stewards 

Data 

Administrator 

Assign  entities  to  data  stewards  by 
information  class  of  the  key  attribute. 

2 

Prepare  and 
Transmit 

Data 

Administrator 

For  each  set  of  entities  to  be  assigned  to  a 
data  steward,  copy  the  hardcopy  entity 
definition(s),  prepare  the  transmittal  sheet, 
and  send  the  sets  to  the  appropriate  data 
stewards. 

3 

Evaluate  and 
Recommend 
attributes 

Steward,  with 

Functional 

Expert(s) 

For  each  assigned  entity,  check  attributes. 

-  Are  entities  and  attributes  used 
appropriately? 

-  Is  the  key  attribute  for  each  appropriate? 

-  Are  all  attributes  standard  data  elements? 

-  Do  any  nonstandard  attributes  merit 
creation  of  a  new  standard  data  element? 

-  Do  the  standard  domains  of  each  attribute 
meet  the  needs  of  this  application? 

-  Are  the  business  rules  reasonable? 

(Refer  to  Section  9.) 

4 

Return 

Recommenda¬ 

tions 

Steward 

For  each  element  recommend  one: 

•  Acceptance  as  submitted 

•  Acceptance  with  specific  modifications 

•  Return  to  developer  or  maintainer  to 
resolve  problems 

Return  recommendations  and  supporting 
material  to  the  Data  Administration  office. 
(Refer  to  Section  9.) 

5 

Evaluate 
and  Act  on 
Recommenda¬ 
tions 

Data 

Administrator 

Review  data  steward's  recommendations. 

With  the  agreement  of  the  developer  or 
maintainer,  resolve  problems  that  require 
only  minor  corrections.  For  issues  that 
require  attention  by  the  developer,  add  to  the 
discrepancy  list. 

Continued  on  next  page 
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3.4.  Receive  and  Evaluate  Data  Model,  continued 


Prepare 

Discrepancy 

Report 


After  reviewing  the  model,  DA  staff  will  compile  the  discrepancy  list  using  the 
Metadata  Discrepancy  Report  (DR)  form  provided  in  Appendix  D,  or  a  similar 
on-line  format.  Assign  each  discrepancy  a  tracking  number.  For  each 
discrepancy,  cite  the  explanation,  and  add  a  sentence  to  instruct  the  developer  or 
maintainer  how  to  correct  the  problem.  DA  will  send  the  discrepancy  report(s)  to 
the  developer/designer,  the  application's  program  manager,  to  the  designated 
metadata  CM,  and  to  the  project's  quality  assurance  manager. 


Track 

Discrepancy 

Resolution 


As  DR  replies  and  metadata  re-submittals  are  received,  DA  will  track  the 
resolution  until  all  discrepancies  are  resolved  satisfactorily,  using  this  procedure. 
The  procedure  applies  to  each  receipt  of  corrections. 


Step 

Action 

1 

Receive  and  log  corrected  model,  definitions,  or  other  material. 

2 

Evaluate,  especially  against  previous  discrepancies.  Resolve  any 
metadata  conflicts  through  the  process  described  in  Review  Submitted 
Data  Model  (General),  steps  2-6,  above. 

3 

Accept  and  close-out  each  corrected  discrepancy.  Keep  all 
documentation  and  correspondence  that  resulted  in  resolving  the 
discrepancy.  Label  and  store  it  by  discrepancy  tracking  number(s). 

4 

Report  the  revised  discrepancy  list  to  the  data  administrator. 

5 

Notify  developer  or  maintainer  of  acceptance  of  closed-out. 

Accept 
Application 
Data  Model 


When  all  discrepancies  have  been  resolved,  the  fleet  logistics  DA  will  accept  the 
data  model,  using  the  following  procedure.  Resolution  of  the  final  item  on  the 
discrepancy  list  initiates  this  acceptance  action. 


Step 

Action 

1 

Check  the  discrepancy  list  for  unresolved  or  inconsistent  issues. 

2 

Notify  the  Data  Administrator  that  all  entities,  elements,  and 
relationships  in  the  application  data  model  are  approved  to  incorporate 
into  the  fleet  logistics  enterprise  data  model. 

3 

Release  the  version  of  the  standard  enterprise  model  that  includes  the 
changes  initiated  by  this  application.  Forward  the  change  notice  to  the 
appropriate  data  stewards,  the  organization  that  generated  the  request  and 
to  the  CG  Data  Administrator  (G-TTC-3) 

4 

Increment  the  version  of  the  enterprise  model,  and  transmit  a  copy  to  the 
repository  CM.  Also  transmit  a  copy  of  the  approved  application  model 
to  the  repository  CM. 

Support  Development  and  Integration  of  Data  Models 


3.5.  Submit  Changes  to  Data  Models 


Introduction  As  the  design  is  reviewed  and  refined,  and  during  the  development  process,  the 
requirement  to  revise  an  application's  data  model  will  occur.  These  steps 
describe  the  process  for  updating  of  the  approved  and  integrated  standard  data 
model  and  keeping  the  application's  current  model  aligned  with  the  standard 
model. 


Responsi¬ 

bility 


The  system  developer  or  maintainer,  data  steward,  or  information  user  requesting 
the  data  model  change  should  perform  the  steps  outlined  in  this  subsection. 


Prepare  The  physical  transfer  of  changes  consists  of  submitting  the  properly  identified 

Metadata  metadata  documentation  to  fleet  logistics  DA.  Preparation  is  important  to  reduce 

Changes  unnecessary  correction  and  re-defmition  during  the  request  review  process.  Use 

the  following  checklist  for  each  revised  entity,  to  ensure  smooth  and  accurate 
merging,  and  to  expedite  acceptance  of  the  revised  model: 


Check  for: 

Criterion: 

Metadata  conflicts  between  proposed 
entity  and  existing  entities  in  the  data 
model. 

Relationship  of  entity  to  contiguous 
entities. 

Conflict  with  current  information 
class  the  entity  would  be  part  of. 

Definition  of  information  class. 

If  an  independent  entity,  proper 
definition. 

Is  it  uniquely  defined? 

Relationship  with  parent  or  child 
entities. 

Is  it  properly  defined? 

Relationship  with  associative 
entities. 

Does  this  relationship  replace  a  many- 
to-many  relationship? 

Relationship  with  Generic  and 
Category  entities. 

Does  this  entity  fit  into  that  Generic 
or  Category  entity? 

Data  quality  factors 

Has  all  data  quality  (validation, 
synchronization,  access,  etc.) 
information  been  provided  for  each 
change?  What  is  the  data  quality 
effect  on  other  standard  systems? 

Impact  on  other  standard  systems. 

Do  any  of  the  proposed  changes  to 
standard  metadata  require  changes  to 
other  standard  systems?  What  is  the 
cost  and  benefit  of  each  change? 

Continued  on  next  page 
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3.5.  Submit  Changes  to  Data  Models,  continued 


Data  Model 

Submittal 

Package 


A  complete  change  request  package  consists  of  the  ER  diagram,  electronic 
version  of  the  model  in  the  prescribed  format,  and  related  hardcopy 
documentation  (such  as  DBDD  and  IDDs).  The  package  should  be  of  a  size  and 
complexity  that  the  proposed  data  model  subset  can  be  understood  and  placed  in 
context  with  other  models  for  related  functions  or  entities.  Changes  from  the 
previously  approved  version  (or  standard  metadata)  should  be  marked  clearly.  A 
Metadata  Submittal  cover  sheet  is  provided  in  Appendix  D. 


Identification  The  data  model  submittal  package  includes  the  following  components; 

of  Submittals 


Component 

Description 

1 

Application,  project,  or  function  name  and  identifier,  and 
abbreviation  (if  any) 

2 

Coast  Guard  sponsoring  organization  and  point  of  contact 

3 

Acquisition  or  funding  organization  and  point  of  contact 

4 

Function  or  project  data  administrator  name  and  organization 

5 

Submittal  date 

6 

Version  number  and  date  of  the  subset  (view)  standard  metadata 
that  was  provided  to  initiate  this  modeling  process 

7 

Version  number  and  date  of  the  enterprise  data  model  the 
proposal  is  being  compared  to 

8 

Information  systems  within  the  CG  with  which  the  application 
shares  data 

9 

Information  systems  outside  the  CG  with  which  the  application 
shares  data 

10 

Information  system(s)  supported  or  affected  by  the  requested 
change(s) 

11 

Model  component  count 

12 

CASE  Tool  (and  version)  used  to  generate  the  E-R  Diagram 

Submittal  After  checking  for  complete  metadata  changes,  submit  the  revision  using  the 

Procedure  following  procedure: _ 


Step 

Action 

1 

Release  the  request  per  the  project’s  operating  procedure.. 

2 

Prepare  transmittal  forms  and  associated  documentation. 

3 

Transmit  through  the  program  manager  to  fleet  logistics  DA. 

4 

Correct  discrepancies  when  notified,  and  resubmit  the  corrected  details. 

5 

When  accepted,  use  the  approved  attributed  data  model  as  the  basis  for 
physical  database  and  application  design. 
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3.6.  Maintain  Configuration  of  Data  Models 


Introduction  This  series  of  procedures  shows  how  to  make  changes,  estimate  the  impact  of 
changes,  and  implement  changes  to  the  metadata  repository. 

Configuration  management  of  data  models  occurs  at  two  levels:  versions  of  the 
application  models  and  versions  of  the  standard  enterprise  data  model. 
Operations  of  (and  user  access  to)  the  fleet  logistics  metadata  repository  are 
described  in  Section  6.  Processing  of  changes  to  metadata  is  described  in 
Section  7. 


Responsi'  Generating  and  submitting  a  change  request  is  the  responsibility  of  the  developer, 
bility  maintainer,  steward,  or  information  user  who  recognizes  the  need.  Reviewing 

and  acting  on  the  request  is  the  responsibility  of  the  fleet  logistics  DA.  The 
version  numbers  for  an  application  model  are  assigned  by  the  application 
system’s  configuration  manager.  The  version  numbers  for  the  fleet  logistics 
standard  metadata  are  assigned  by  DA  repository  administrator.  . 


Configuration  The  repository  administrator  ensures  that  any  changes  requested  to  or  data 
Management  inquiries  from  the  fleet  logistics  application  and  standard  enterprise  models  are  in 
of  Metadata  relation  to  the  most  current  version  of  each  of  those  models.  This  assures  system 
developers,  system  maintainers,  data  stewards,  and  users  that  any  data  entity  they 
are  referencing  is  current  and  approved.  Changes  to  the  fleet  logistics  data 
model,  conversely,  may  require  update  of  systems  and  applications  which  use 
that  portion  of  the  standard  data  model. 


Continued  on  next  page 
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3.6.  Maintain  Configuration  of  Data  Modeis,  continued 


Metadata  Changes  that  have  been  approved  by  the  DA  are  recorded  in  the  fleet  logistics 

Repository  metadata  repository.  The  following  is  a  brief  description  of  the  CASE  repository 

that  is  the  underlying  platform  of  the  data  repository. 

The  fleet  logistics  repository  is  comprised  of  a  Data  Dictionary  and  Data 
Encyclopedia. 

•  The  Data  Dictionary  is  defined  as  the  storage  site  (logical  and/or  physical) 
of  data  structure  definitions,  including  the  listing  of  which  systems  have 
instances  of  which  standard  data  elements. 

•  The  Data  Encyclopedia  is  defined  as  the  storage  site  of  system  parameters, 
such  as  data  structure  definitions,  process  definitions.  Data  Flow  Diagrams, 
and  other  items  pertinent  to  the  development,  operation,  and  maintenance  of 
computer  systems  software  and  use  of  the  standard  information  resource. 

The  fleet  logistics  metadata  repository  is  defined  as  the  collection  of  all 
information  pertaining  to  the  encyclopedia  plus:  pre-planning  documentation, 
baselines,  group  charters,  project  management  information,  correspondence 
pertinent  to  the  development  process,  repository  CM  information,  and  any  other 
information  related  to  the  process  of  generating  the  computer  system  during  its 
entire  life-cycle. 


Operation  of  the  fleet  logistics  metadata  repository  is  described  in  Section  6. 


Active  and  The  fleet  logistics  metadata  repository  is  a  “passive  repository”  from  the  system 
Passive  developer’s,  maintainer’s,  and  user’s  point  of  view. .  In  such  repositories,  the 

Repositories  analyst  “checks  out”  pertinent  information  for  his  task  from  the  master  copy  of  the 
encyclopedia,  performs  his  work  on  that  information,  and  then  checks  it  back  into 
the  encyclopedia.  For  fleet  logistics  standard  metadata,  the  developer  or  maintainer 
checks  out  the  application’s  view  or  subset  of  the  standard  data  model,  applies  it  to 
the  application,  and  then  requests  changes  that  will  reconcile  the  completed 
application  model  to  the  standard  data  model.  The  fleet  logistics  DA  will  make  the 
changes  to  the  standard  enterprise  data  model  after  review  and  approval. 

Data  models  at  the  application  system  or  business  process  level  are  likely  to  employ 
an  active  encyclopedia,  where  the  developer  or  analyst  directly  works  on  the  master 
copy  of  the  encyclopedia.  The  change  request  process  is  designed  to  bring  the 
completed  application  (local)  metadata  into  congruence  with  the  fleet  logistics 
standard  metadata  by  resolving  differences  that  arise  during  analysis  and 
development. 


Continued  on  next  page 
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3.6.  Maintain  Configuration  of  Data  Modeis,  continued 


Online 
Access  to 
Repository 


Developers  and  maintainers  of  fleet  logistics  information  systems,  data  stewards, 
and  users  of  enterprise  data  are  likely  to  need  access  to  current  standard 
metadata.  Use  this  procedure  to  obtain  user  access  to  the  fleet  logistics  metadata 
repository. 


Step 

Action 

1 

Prepare  Repository  User  Request  (form  supplied  in  Appendix  D). 

2 

Submit  request  to  fleet  logistics  DA  office. 

3 

After  notification  letter  is  received,  log  in,  change  the  account’s 
password,  and  set  user  options. 

4 

Perform  status  requests,  send  email,  and  download  metadata  as  provided 
in  your  profile  of  user  privileges. 

5 

When  your  need  for  access  to  the  repository  is  ended,  notify  the 
repository  system  administrator  to  terminate  your  account. 

Repository 

User 

Privileges 


Users  of  the  fleet  logistics  metadata  repository  are  typically  assigned  the 
following  account  privileges: 

View  status  of  submitted  metadata  change  requests  (for  user’s  system(s)) 
View  list  of  registered  standard  systems 
Perform  “where-used”  queries  for  standard  data  elements 
Display  and  download  user-specified  metadata  views 


Fleet  logistics  metadata  repository  operations  are  described  in  Section  6.  Users 
of  this  repository  are  likely  to  require  CG-wide  metadata  also.  The  Coast  Guard 
Data  Administration  Dictionary  System  (DADS)  is  described  briefly  in  Section 


12. 
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3.7.  Generate  Data  Models  from  the  Repository 


Introduction  This  series  of  steps  shows  how  to  select  entities  and  package  them  into  a  view  or 
subset.  These  views,  whether  on-line  or  in  hardcopy  form,  are  essential  in 
helping  the  system  developer  or  analyst  to  visualize  the  data  model  and  its 
individual  components.  Physical  diagrams  can  both  validate  an  assumption 
concerning  an  entity,  as  well  as  illustrate  any  deficiencies  in  the  design  and 
placement  of  that  entity  within  the  data  model.  These  instructions  assume  the 
reader  has  obtained  a  user  account  for  the  fleet  logistics  metadata  repository 
system,  as  described  in  the  previous  subsection. 


Extract 

Metadata 

Objects 


Generate 
Requested 
Data  Model 


Use  this  procedure  to  extract  metadata  objects  from  the  repository  when 
requested  by  a  developer  or  other  analyst. 


Step 

Action 

1 

Log  on  to  the  repository  system,  and  select  the  front-end  query  tool  for 
the  standard  metadata  database. 

2 

Select  the  model  or  subset  to  view  by  model  name  and/or  version 
number,  or  create  a  user-specified  view. 

3 

Query  by  one  of  the  following  items: 
entity  types 
entity  name 
relationship  types 

Use  this  procedure  to  generate  a  requested  data  model,  such  as  an  application 
model  or  user  view. 


Step 

Action 

1 

Determine  whether  the  model  or  subset  extracted  is  the  one  appropriate 
to  the  analysis  at  hand. 

2 

Select  the  method  to  generate  the  data  model  -  on  screen,  to  a  file, 
hardcopy,  etc. 

3 

Save  the  requested  view,  if  desired,  for  future  reference. 
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3.8.  Coordinate  Data  Model  Development  and  Integration 


Purpose  This  series  of  tasks  describes  the  proactive  coordination  and  integration  activities 

of  fleet  logistics  DA,  among  the  application  systems  that  are  in  analysis  and 
design  phases.  By  monitoring  and  guiding  the  development  of  process  and  data 
definitions,  interfaces,  and  uses  of  data,  each  system's  metadata  will  be  closer  to 
standard  when  submitted.  The  goal  of  this  effort  is  to  minimize  the  amount  of 
rework  required  after  submittal  of  data  models  and  data  element  definitions. 

The  role  of  this  coordination  and  guidance  task  is  to  allow  system  designers  the 
room  to  think  creatively,  but  then  to  identify  commonality  among  their  process 
and  data  definitions.  This  metadata  support  permits  designers  to  achieve 
metadata  consistency  and  full  use  of  the  standard  data  resource  before  submittal. 
This  will  help  to  ensure  a  greater  degree  of  success  upon  initial  submittal  of  the 
data  model. 

This  coordination  role  will  be  performed  for  systems  that  have  been  authorized 
for  design,  but  have  not  yet  submitted  Database  Definition  Documents.  It  can  be 
performed  as  part  of  the  system  design  phase  as  described  in  Section  8. 


Responsi-  Performing  the  duties  described  in  this  subsection  is  the  responsibility  of  the  fleet 
bility  logistics  DA  or  a  designee  of  the  DA. 


Provide 
Coordination 
and  Oversight 


The  following  actions  constitute  the  metadata  coordination  role: 

1 .  Provide  initial  guidance  and  instruction  regarding  data  standards  and 
administration  requirements. 

2.  Review  each  system's  design  documents  to  understand  the  uses  of  data  in 
each  development  project. 

3.  Review  each  application's  process,  data,  and  control  descriptions, 
decompositions,  and  models. 

4.  Guide  developers,  system  maintainers,  and  users  of  standard  data  in  the  use 
of  data  modeling,  documentation  standards,  and  application  of  standard 
data  definitions. 

5.  Recognize  and  verify  opportunities  for  metadata  commonality. 


Continued  on  next  page 
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3.8.  Coordinate  Data  Model  Development  and  Integration, 

Continued 


Provide  Initial  Fleet  logistics  DA  will  provide  information  as  training  or  a  series  of  briefings  to 
Guidance  the  program  management  and  development  teams  for  each  application.  This 

proactive  outreach  role  provides  the  development  team  (or  data  steward  or  data 
users)  with  data  compatibility  goals,  sets  achievable  expectations,  and  shows  the 
team  how  to  use  the  standard  data  tools  to  speed  up  development.  A  standard  set 
of  briefing  materials  will  be  provided.  These  materials  are  described  in  Section 
8. 


Review  Review  each  system's  preliminary  design  documents,  functional  requirements 

Design  documents,  and  database  and  interface  design  documents  as  they  are  submitted  at 

Documents  the  appropriate  project  milestones,  to  understand  the  uses  of  data  in  each 

development  project.  The  review  of  data  standards-related  deliverables  is 
coordinated  by  DA,  with  data  steward  participation. 

Database  Design  Documents  (DBDD)  and  Interface  Design  Documents  (IDD) 
are  the  program  milestone  documents  that  include  most  data  standards 
information.  Software  Requirements  Documents,  Functional  Descriptions,  and 
System/Segment  Specifications  include  process  definitions  and  are  useful  to 
evaluate  data  security,  integrity,  and  synchronization  requirements.  As  part  of 
the  coordination  function  is  to  show  the  development  team  how  to  include 
metadata  in  these  documents,  the  DA's  review  of  these  documents  ensures 
compliance  at  the  appropriate  milestones  as  described  in  Section  11. 


Continued  on  next  page 
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3.8.  Coordinate  Data  Model  Development  and  Integration, 

Continued 

Review  From  process  and  data  models  in  CASE  tools,  the  DA  analyst  can  understand  the 

Process  and  use  of  data  in  the  application,  and  identify  potential  problems  and  opportunities. 

Data  Models  The  process  model  provides  a  basis  for  security  requirements/risk  analysis,  and 
for  identification  of  potential  data  synchronization  and  integrity  problems.  The 
process  model  also  shows  opportunities  for  use  of  standard  data,  adaptation  of 
standard  processes  and  existing  software,  and  development  of  data  that  is  usable 
by  other  systems. 

The  data  model  provides  the  first  look  at  data  entities,  with  the  opportunity  to 
match  the  system's  data  requirements  to  standard  data  entity  and  relationship 
types.  DA  must  facilitate  matching  to  standard  entities,  and  encourage  limiting 
definition  of  unique  entities  to  necessary  cases. 


A  major  challenge  of  a  central  data  resource  is  the  goal  of  compatible,  portable, 
consistent,  high-quality  data  from  applications  that  are  developed  at  different 
times  by  different  teams  using  different  tools.  In  addition,  human  nature  leads 
most  people  to  consider  their  own  problem  as  unique,  and  their  own  perspectives 
as  the  best  possible.  In  information  system  development,  these  forces  combine  to 
skew  development  into  uniquely  defined,  specialized  "stovepipe"  systems.  The 
current  mandate  for  compatible  systems  and  a  central  data  resource  requires 
aggressive  and  persistent  guidance  and  support  to  each  development  team. 

Verify  From  the  information  gathered  through  review  of  materials  and  communication 

Opportunities  with  designers,  identify  the  potential  opportunities  for  common  definitions,  use 
for  Metadata  of  existing  data,  and  consistent  interfaces.  For  each  opportunity,  reconcile  the 
Commonality  entities  amongst  the  different  design  documents  from  both  the  standard  data 

model  and  other  systems  which  may  currently  be  in  development  for  identical, 
similar,  and  different  entities,  as  well  as  identical  or  similar  entities  which  have 
different  relationships. 

Continued  on  next  page 
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3.8.  Coordinate  Data  Model  Development  and  Integration, 

Continued 


Coordinate  Data  Administration  staff  will  coordinate  the  process  of  ensuring  common 
and  Negotiate  metadata  among  the  systems  in  design  phases.  When  opportunities  for 
Definitions  commonality  are  found,  the  designated  facilitator  will: 


Step 

Action 

1 

Coordinate  with  the  development  teams  to  make  a  common  item  out  of 
slightly  different  ones. 

2. 

Coordinate  the  negotiation  among  the  concerned  development  teams,  to 
achieve  commonality  without  compromising  requirements. 

3 

Recommend  solutions  that  meet  the  needs  of  the  CG  information 

resource. 

4 

Call  upon  management  of  system  developers  and  maintainers  to  make 
decisions  that  the  principals  may  not  have  the  authority  to  make. 

5 

Document  the  results  of  negotiations  and  findings. 

Integrate 

Standard 

Definitions 


The  data  steward  for  a  particular  data  entity  will  facilitate  agreement  between 
two  or  more  development  teams  regarding  a  data  entity  and/or  data  element 
definition,  term  definition,  or  interface.  The  designated  DA  staff  will  incorporate 
the  newly  agreed  item  into  the  fleet  logistics  enterprise  data  model  and  metadata 
repository. 
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3.9.  Improve  the  Data  Model  Development  and  Integration 
Process 


Purpose  As  part  of  the  review  and  negotiation  cycles  that  are  described  previously,  issues 

will  be  raised  and  refinements  will  be  negotiated  that  will  improve  the  data 
modeling  and  definition  process.  These  improvements  must  be  documented  and 
incorporated  into  the  DA  system.  The  following  procedures  show  how  to 
document  and  submit  the  typical  kinds  of  decisions,  refinements,  and  lessons- 
leamed  as  they  become  apparent. 


Responsi-  The  individuals  who  are  working  with  development  teams  to  standardize  the 

bility  models  are  in  the  best  position  to  recommend  improvements  to  this  process.  The 

standards  and  the  process  must  improve  continuously  if  it  is  to  meet  the  changing 
needs  of  the  fleet  logistics  community.  Attention  to  this  duty  is  as  important  as 
any  other  standardization  task. 


Identify  Metadata  quality  issues  include  conditions  that  harm  the  validity  of  a  data 

Metadata  standard,  defeat  security  principles,  and  cause  data  to  be  useless  or  deficient 

Quality  issues  across  the  data  model. 

The  following  procedures  describe  the  general  actions  to  address  metadata 
quality  issues. 


Step 

Action 

1 

Record  and  analyze  those  instances  when  metadata  quality  issues  occur. 

2 

Identify  the  recurrent  problems  and  determine  the  causes. 

3 

Prepare  metadata  changes  according  to  normal  procedures  (see  the  sub¬ 
section  "Submit  Metadata  Changes"). 

4 

Submit  metadata  changes  according  to  normal  procedures  (see  the  sub¬ 
section  "Submit  Metadata  Changes"). 

Continued  on  next  page 
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3.9.  Improve  the  Data  Model  Development  and  Integration 
Process,  continued 


Identify 
Requirements 
for  Data 
Element 
Standardization 


Refinements  in  data  modeling  practice  that  improve  the  clarity  of  the  data  will 
help  system  developers  define  and  propose  more  useful  data  elements.  The  DA 
process  must  remain  receptive  to  improvement  and  open  to  inclusion  of  new 
techniques  and  practices. 

The  following  procedures  describe  the  general  actions  to  address  deficiencies  in, 
or  to  make  improvements  to,  the  metadata  standardization  process. 


Step 

Action 

1 

Record  and  analyze  typical  errors  system  designers,  data  stewards, 
and  users  make  when  proposing  new  data  elements,  entities,  and 
definitions.  Formalize  requirements  that  are  imposed  by  the  fleet 
logistics  data  sharing  community  that  may  not  be  apparent  from  a 
subset  view  of  the  data. 

2 

Identify  recurrent  problems  or  inefficiencies  in  the  submittal  and 
review  process,  and  determine  the  causes. 

3 

Review  any  "lessons  learned"  documentation  from  previous  system 
design  efforts  and  determine  if  any  of  these  lessons  apply  to  the 
problems  identified. 

4 

From  the  data  stewards'  monitoring  of  data  quality  (refer  to  Section 

8),  identify  any  flaws  in  the  data  model  or  faults  in  data  element 
definitions  that  cause  or  facilitate  data  errors. 

5 

Review  the  current  academic  research  on  data  modeling  and 
determine  if  any  of  the  new  thinking  on  data  modeling  applies  to  the 
problems  identified. 

6 

Refine  the  structure  the  fleet  logistics  enterprise  data  model,  if 
necessary,  using  the  standard  updating  and  CM  procedures  outlined  in 
this  manual. 

Continued  on  next  page 
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3.9.  Improve  the  Data  Model  Development  and  Integration 
Process,  continued 


Identify 
Requirements 
for  New 
Information 
Ciasses 


As  the  current  data  models  and  data  standards  are  applied  to  fleet  logistics 
business  processes,  old  processes  and/or  assumptions  may  need  to  be  updated  or 
discarded.  If  a  significant  number  of  entities  appear  to  be  misplaced  in  their 
current  information  classes,  or  a  functional  organization  has  created  a  new 
division  which  controls  certain  entities,  DA  may  need  to  create  a  new 
information  class  within  the  fleet  logistics  enterprise  data  model  that  reflects 
these  new  business  conditions. 


Careful  DA  review  is  important  because  the  perspective  of  a  business  process  or 
application  may  show  the  need  for  a  new  information  class,  entity,  relationship, 
or  other  item,  but  the  enterprise  view  may  account  for  that  requirement 
differently. 

The  following  procedures  describe  the  general  actions  to  identify  and  create  a 
new  information  class. 


Step 

Action 

1 

Verify  that  the  new  information  class  is  unique  within  the  model. 

2 

Prepare  a  new  E-R  diagram  reflecting  the  information  class  (and/or  other 
proposed  change). 

3 

Construct  key-based  (logical)  model  for  that  portion  of  the  data  model. 

4 

Submit  for  DA  review  and  response. 

Identify  New 
Terms  for 
Metadata 
Glossary 


New  models,  concepts,  and  business  practices  will  probably  give  rise  to  new  data 
entities,  terms,  and  other  items  that  need  to  be  defined,  as  well  as  the  refinement 
of  existing  definitions.  The  fleet  logistics  metadata  glossary  should  reflect  these 
changes,  as  well. 


The  following  procedures  describe  the  general  actions  to  identify  and  create  new 
terms  for  the  glossary. 


Step 

Action 

1 

Create  a  new  entity,  key  term,  or  other  definition,  using  the  standard 
procedures  outlined  in  this  document. 

2 

Submit  for  acceptance  and  integration,  using  the  standard  procedures 
outlined  in  this  document. 

3 

Upon  acceptance.  Configuration  Management  enters  the  new  definition 
into  the  standard  metadata  glossary. 
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STANDARDIZE  DATA  ELEMENTS 


4.1.  Overview 


introduction  Data  are  the  representation  of  facts,  concepts,  or  instructions  in  a  manner  that  is 
suitable  for  communication,  interpretation,  or  processing  by  human  or  automated 
means.  Data  standardization  is  the  application  of  formalized  rules  for  defining 
and  composing  data.  Just  as  an  enterprise  or  organization  must  manage  its  other 
resources  effectively,  it  must  also  effectively  manage  its  data  resources.  Data 
standards  allow  for  this  effective  management  of  data. 


In  this  Section  This  section  contains  the  following  data  element  topics: 


Topic 

Section 

Basic  Concepts 

4.2 

Procedures  to  Standardize  Data  Elements 

4.3 

Procedures  to  Approve  Data  Elements 

4.4 

Maintain  Data  Elements 

4.5 

Improve  the  Data  Element  Definition  Process 

4.6 

Continued  on  next  page 
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4.1.  Overview,  Continued 


Relationship 
of  Data 
Models  and 
Data 

Elements 


The  data  required  by  an  organization  can  be  graphically  represented  in  data 
models  (refer  to  Section  3,  Support  Integration  of  Data  Models,  and  Section 
2.5,  Architectural  Framework  for  Information  Systems,  for  more  details  on 
Data  Models  and  how  they  fit  into  the  overall  fleet  logistics  Data  Architecture). 
Data  models  contain  entities,  the  relationships  between  the  various  entities,  and 
entity  attributes. 


Standard  data  elements  are  the  representation  of  entity  attributes  (that  is,  the  data 
requirements  of  an  organization)  in  a  form  usable  within  either  a  manual  or 
automated  data  application  (such  as  a  fill-in  form).  Each  standard  data  element  is 
associated  with  one  and  only  one  entity  from  the  standard  enterprise  data  model. 
The  entity  attribute  becomes  approved  as  a  standard  data  element  after 
application  of  data  standardization  procedures,  such  as  those  described  in  this 
section. 


Advantages  of 
Using 

Standard  Data 
Elements 


Use  of  standard  data  elements  enhances  interaction  among  information  systems, 
facilitates  increased  data  sharing,  reduces  data  handling  costs,  and  leads  to  better 
data  accuracy,  consistency,  and  timeliness.  The  data  element  standardization 
procedures  in  this  section  provide  the  framework  necessary  to  maximize  the  data 
sharing  opportunities  throughout  the  fleet  logistics  enterprise. 
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4.2.  Basic 


Concepts 


Introduction  This  subsection  describes  the  basic  concepts  of  data  element  standardization  and 
the  data  element  standardization  process. 


In  this  Section  This  subsection  contains  the  following  topics: 


Topic 

Refer  to 
Subsection 

Objectives  Achieved  by  Standardizing  Data  Elements 

4.2.1 

Definitions  and  Explanations 

4.2.2 

Data  Element 

4.2.3 

Components  of  a  Data  Element  Name 

4.2.4 

Data  Element  Life  Cycle 

4.2.5 

Roles  and  Responsibilities  in  Standardizing  Data  Elements 

4.2.6 

The  Process  of  Standardizing  Data  Elements 

4.2.7 
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4.2.1.  Objectives  Achieved  by  Standardizing  Data  Elements 


Background  Standardizing  data  elements  achieves  a  number  of  the  objectives  described  in 
Section  2,  Fleet  Logistics  Data  Administration  Strategic  Plan,  Subsection 
2.1,  Goals  and  Objectives  of  Fleet  Logistics  Data  Administration.  In 
standardizing  the  way  data  elements  are  named  and  defined,  uniform  names  and 
rigorous  definitions  are  developed  for  all  shareable  data  elements  used  within  the 
fleet  logistics  environment. 


Purpose  Standardizing  data  elements  helps  eliminate  duplication  and  incompatibilities  in 

the  collection,  processing,  and  dissemination  of  data,  increasing  their  usefulness. 
It  also  helps  meet  the  requirements  for  sharing  data  among  the  Coast  Guard  fleet 
logistics  information  systems  and  with  systems  outside  of  the  fleet  logistics 
environment. 


Supported  The  primary  objectives  achieved  through  standardizing  data  elements  are: 

Objectives 

1.  Integrated  operations  among  the  various  organizations  of  Coast  Guard 
Engineering  Logistics 

2.  Minimized  redundancy 

3.  Maximum  effectiveness  in  processing  and  storing  data 

4.  Maximum  integrity  (accuracy  and  consistency)  of  data 

5.  Reduced  cost  and  time  to  develop,  field,  and  maintain  information 
systems 

These  objectives  are  components  of  the  broader  objectives  enumerated  in 
Section  2,  Fleet  Logistics  Data  Administration  Program.  Thus,  those  broader 
objectives  directly  help  achieve  all  five  data  element  standardization  objectives. 


Examples  of 
Support  for 
the  Objectives 


1 .  All  organizations  would  use  the  same  definition,  format,  etc.,  for  any  given 
entity  attribute. 

2.  Using  a  common  data  element  would  eliminate  redundant  definitions  for  the 
same  entity  attribute,  reducing  the  cost  to  maintain  data  elements  because  a 
single  standard  element  replaces  multiple,  separately  maintained  data 
elements. 

3.  The  process  of  standardizing  the  data  elements  forces  greater  understanding 
of  the  data  and  how  it  is  used  in  the  business.  This  greater  understanding  can 
aid  in  articulating  requirements. 

4.  Using  a  common  data  element  improves  the  possibilities  for  constant 
synchronization  for  that  element  from  one  physical  database  to  another. 
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4.2.2  Definitions  And  Explanations 


Introduction  To  understand  data  standardization,  we  should  first  define  the  concept  of  “data.” 

The  word  "data"  can  and  is  used  in  a  number  of  ways.  Reviewing  some  of  these 
uses  will  aid  in  clarifying  this  section's  key  phrase,  "data  element." 

Use  this  section  for  definitions  and  for  background  information  about: 

•  explanations  of  physical  and  logical  data 

•  difference  between  physical  and  logical  data 

•  data  elements 

•  components  of  a  data  element 


Physical  Data  "Physical"  and  "logical"  are  terms  used  to  describe  different  representations  of 

VS.  Logical  data. 

Data 

Physical  data  refers  to  the  definition  of  data  as  it  is  contained  in  technological  or 
physical  configurations.  These  may  be  a  paper  form,  automated  database,  or 
some  other  representation.  The  definition  of  the  physical  data  takes  into  account 
the  constraints  of  the  physical  environment. 

Logical  data  refers  to  the  definition  of  data  as  it  represents  the  structure  of  or 
relationships  among  the  various  levels  of  data  components,  such  as  data  entities 
and  entity  attributes  (refer  to  Section  3,  Integrate  Data  Models,  for  more 
information  on  data  entities  and  entity  attributes). 


Continued  on  next  page 
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4.2.2  Definitions  And  Explanations,  Continued 


Relationship 
between 
Physical  Data 
and  Logical 
Data 


To  derive  logical  data,  existing  values  of  physical  data  are  analyzed  for  their: 

•  physical  characteristics 

•  various  business  names 

•  use  or  purpose  within  the  business 


Based  on  this  analysis,  common,  optimal  structures  (logical  data)  are  formed. 
Logical  data  can  be  standardized  through  the  application  of  approved  data 
standards  and  rules.  The  "logical"  representation  of  data  is  used  to  construct  new 
or  revised  representations  of  data  in  an  information  system. 


The  following  two  subsections  present  examples  of  physical  data  and  logical 
data. 


Description  of 
a  Physical 
Data  Field 


For  automated  databases  the  term  "field"  is  used  to  indicate  a  unit  of  physical 
data.  A  database  is  said  to  contain  a  field  for  each  component  of  the  physical 
data. 


Example  of  For  an  automated  database  of  employee  data,  for  example,  the  fields  of  the 
Physical  Data  physical  data  might  be: 

•  name 

•  date  of  hire 

•  current  job  grade 

•  social  security  number,  etc. 

Such  a  database  might  be  used  to  do  the  weekly  payroll.  Since  only  certain  data 
about  an  employee  is  required  to  do  payroll,  this  database  would  be  a  subset  of 
the  more  encompassing  logical  representation  which  might  include  all  job  grades 
since  date  of  hire.  The  descriptions  of  each  of  these  fields  would  provide  the 
physical  characteristics  peculiar  to  the  automated  database  technology  such  as 
the  physical  sequence  in  which  the  fields  are  to  be  recorded. 


Continued  on  next  page 
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4.2.2  Definitions  And  Explanations,  Continued 


Definition  of  Metadata  is  a  set  of  attributes  that  describes  and  defines  data.  In  the  data 

Metadata  for  standards  world,  this  idea  translates  into  the  following  cliche:  metadata  is  data 

Physical  Data  about  data. 

The  metadata  for  physical  data  is  a  collection  of  characteristics  that  describe  the 
contents  of  the  field.  Each  physical  data  field  is  described  by  a  set  of  these 
characteristics.  Examples  of  characteristics  are: 

•  name 

•  maximum  length 

•  type 

•  code  description 

Description  of  Logical  data  refers  to  the  components  making  up  the  rational  structure  of 
Logical  Data  business  data. 

As  in  the  example  for  physical  data,  an  example  of  logical  employee  data  might 
be: 

•  name 

•  date  of  hire 

•  positions  held  since  hire 

How  is  this  different  from  physical  data?  Physical  representations  may  omit 
some  components,  such  as  “non-current  positions.”  Or  they  may  contain 
instances  of  only  those  components  meeting  certain  criteria,  such  as  only  the 
names  of  employees  hired  after  January  1,  1985. 

The  logical  representation,  on  the  other  hand,  accounts  for  all  representations  of 
the  physical  data. 

Definition  of  The  metadata  for  logical  data  is  a  collection  of  characteristics  that  describe  the 
Metadata  for  contents  of  the  particular  component  of  the  logical  data.  Examples  of 
Logical  Data  characteristics  are: 

•  name 

•  definition 

•  identification  of  entity  to  which  this  logical  data  belongs 


Example  of 
Logical  Data 
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4.2.3  Data  Element 


Introduction  Logical  data  are  represented  in  a  data  architecture  by  data  entities  and  data 

elements.  As  is  stated  in  Section  3.2,  Data  Modeling  Concepts,  all  entities  in 
data  models  have  properties  or  characteristics  which  are  used  to  describe  and 
distinguish  them.  These  characteristics  are  called  entity  attributes.  Entity 
attributes  form  the  basis  for  data  elements.  A  data  element,  in  fact,  is  an  entity 
attribute  which  has  been  more  rigorously  defined  with  a  set  of  data  element 
attributes. 


Characteri¬ 
stics  of  Data 
Elements 
(Data  Element 
Attributes) 


Each  data  element  has  its  own  set  of  characteristics  called  data  element 
attributes.  They  identify  and  describe  the  data  element,  provide  a  rigorous 
definition,  and  specify  its  context.  Examples  of  such  attributes  are: 

•  the  name  of  the  data  element 

•  the  definition  of  the  data  element 

•  a  list  of  characteristics  of  the  data  element 

•  descriptions  of  the  characteristics 


A  full  set  of  these  data  element  attributes  are  listed  in  Appendix  D,  Data 
Element  Attribute  Descriptions. 


Terminology  The  following  table  defines  the  general  data  terms  we  use  in  data  standardization, 
showing  the  relationship  between  the  terms  entity  attribute  and  data  element 
attribute. 


Term 

Description 

Entity 

A  thing,  fact,  or  concept  that  is 
important  to  an  enterprise  and  for 
which  data  is  collected 

Entity  attribute 

A  characteristic  of  an  entity,  such  as 
“customer's  street  address;”  when 
defined  for  use  in  applications,  it 
becomes  a  data  element 

Data  element 

A  more  rigorously  defined  entity 
attribute.  An  example  is  “Coast 
Guard  customer's  street  address,” 
which  requires  a  name  in  a  standard 
format,  definition  in  a  specified 
format,  as  well  as  other  components 

Data  element  attribute 

A  characteristic  of  a  data  element, 
such  as  the  maximum  number  of 
characters,  or  the  data  type 
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4.2.4  Components  of  a  Data  Element  Name 


Introduction  A  crucial  attribute  of  every  data  element  is  its  name.  The  data  element  name  is 
the  primary  attribute  that  a  data  element  user  will  use  in  locating  a  data  element 
that  s/he  wants  to  use  in  system  development.  As  data  standardization  dictates, 
the  name  must  be  unique  and  follow  a  prescribed  format.  As  defined  by  Coast 
Guard  requirements,  a  data  element  name  within  the  DA  community  may  consist 
of  up  to  the  following  five  components: 

•  modifier  preceding  the  prime  word 

•  a  prime  word 

•  modifier(s)  following  the  prime  word 

•  a  class  word 

•  qualifier(s) 

The  following  table  shows  these  components  as  they  appear  in  a  data  element 
name,  shows  their  placement  within  the  data  element  name,  tells  the  number  of 
instances  allowed  for  each,  notes  whether  the  component  is  required  or  optional, 
and  notes  any  special  requirements  for  that  component.  The  data  element  can 
have,  at  a  maximum,  9  components.  These  components  are  described  in  detail  in 
the  topics  below. 


Modifier 

Preceding 

Prime 

Word 

Prime  Word 

Modifier(s) 

Following 

Prime  Word/  Class 
Word  Modifier 

Class  Word 

Qualifier(s) 

Number 

0...1 

1 

If  the  Modifier 
preceding  the  Prime 
Word  =  0,  then  0...4 

If  the  Modifier 
preceding  the  Prime 
Word  =  1,  then  0...3 

In  any  case,  0...1  Class 
Word  Modifier 

1 

1..2 

Presence 

Required 

Optional 

Required 

Requirement 

Adjective  or 
noun 

Must  be  1st  or 

2nd  component, 
must  be  before 
Class  Word 

Adjective  or  noun 

A  Class  Word 
cannot  be  used 
as  a  Prime  Word 
or  a  Modifier 

Continued  on  next  page 
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4.2.4  Components  of  a  Data  Element  Name,  Continued 


Naming  A  data  element  naming  convention  is  critical  to  the  success  of  a  data 

Convention  administration  program.  A  naming  convention  can  facilitate: 

•  greater  efficiency  of  data  handling 

•  cost  savings  in  reduced  computer  time 

•  reduced  confusion  among  both  staff  and  management. 

Naming  conventions  for  fleet  logistics  follow  the  guidelines  set  forth  for  the 
Coast  Guard  COMDTINST 5230A2A,  Section  3,  and  the  Department  of  Defense 
in  DoD  Data  Element  Standardization  Procedures  (DoD  8320.1-M-l),  January 
1993,  Chapter  3.D,  Data  Element  Naming. 


Prime  Word  Within  the  framework  of  a  data  model,  a  prime  word  is  equivalent  to  the  name  of 
an  entity  identified  in  a  data  model.  A  prime  word  identifies  and  describes  the 
object  (entity)  being  defined  and  characterized  by  a  data  element.  It  is  a  person, 
place,  thing,  or  event. 

For  example,  fleet  logistics  might  need  to  maintain  information  about  vendors,  so 
an  entity  named  vendor  would  exist  in  the  fleet  logistics  data  model  (see  Section 
3,  Integrate  Data  Models,  for  more  information  on  data  models).  The  prime 
word  for  any  entity  attribute  (and,  by  extension,  any  data  element)  that  is 
associated  with  this  entity  would  therefore  also  be  vendor.  By  including  the 
prime  word  in  a  data  element  name,  the  data  element  identifies  precisely  the 
entity  to  which  it  refers. 

Coast  Guard-specific  prime  words  are  centrally  controlled  and  maintained  by  the 
Coast  Guard  Data  Administrator.  Fleet  logistics  DA  coordinates  the  Coast  Guard 
prime  word  list  with  the  prime  word  lists  of  DoD  and  other  customer  and  supplier 
organizations  for  use  within  fleet  logistics.  Proposals  for  new  prime  words  must 
be  based  on  an  expansion  of  the  fleet  logistics  data  model  and  submitted  for 
approval  (refer  to  Section  3.4,  Receive  and  Evaluate  Data  Model  for  more 
information  on  the  coordination  of  the  CG  data  model  and  data  element 
development,  and  to  Section  4.4,  Procedures  to  Approve  Data  Elements,  for 
more  information  on  the  data  element  approval  process).  Words  used  as  prime 
words  in  some  data  element  names  may  be  used  as  modifiers  in  other  data 
element  names. 

Example:  Vendor _ 

Continued  on  next  page 


4-10 


standardize  Data  Elements 


4.2.4  Components  of  a  Data  Element  Name,  Continued 


Prime  Word  Prime  word  modifiers  are  optional  nouns  or  adjectives  which  further  refine  and 
Modifiers  categorize  the  prime  word.  Because  higher-level  entities  and  sub-entities  on  a 

data  model  describe  super-categories  and  sub-categories  of  entities,  either  the 
higher-level  entities  or  sub-entities  (or  a  combination  of  both)  are  used  as  the 
modifiers  to  the  respective  prime  word. 

For  example,  fleet  logistics  might  be  interested  in  the  mailing  address  of  a 
vendor.  There  would  therefore  exist  a  sub-entity  to  vendor  called  mailing- 
address. 

Example:  Vendor  Mailing-address 

Note  that  if  there  are  multiple  modifiers,  they  are  placed  left-to-right  within  the 
data  element  name  from  specific  to  general. 

Example:  Vendor  Headquarters  Mailing-address 

Also  note  that  only  one  Prime  Word  Modifier  may  be  placed  before  the  Prime  Word. 


Class  Word  A  class  word  identifies  and  describes  the  use  and  purpose  of  data.  In  the  data 

element  name,  a  class  word  designates  the  type  of  information  maintained  about 
the  associated  prime  word.  Examples  of  class  words  are  code,  name,  and 
quantity.  Additionally,  a  data  element’s  associated  class  word  establishes  the 
domain  into  which  the  data  for  that  data  element  fits. 

Determining  the  category  or  class  of  data  should  be  the  first  step  in  developing  a 
data  element  name.  Refer  to  Section  4.3,4,  Identify  and  Define  Data  Element 
Attributes,  the  discussion  Identify  the  Class  Word  in  the  Data  Element  Name, 
for  more  information  on  that  step  in  data  element  name  development. 

Because  the  categories  they  describe  are  broad,  there  are  relatively  few  class 
words.  The  instances  that  a  data  element  developer  will  need  to  create  a  new 
class  word  will  be  relatively  few.  Proposals  for  new  class  words  must  be 
submitted  to  fleet  logistics  DA  for  approval.  A  list  of  currently  approved  class 
words  are  in  Appendix  C,  Class  Word  Descriptions. 

Example:  Vendor  Mailing-Address  Name _ 

Continued  on  next  page 


4-11 


Standardize  Data  Elements 


4.2.4  Components  of  a  Data  Element  Name,  Continued 


Class  Word  A  Class  Word  Modifier  is  an  optional  adjective  or  noun  that  is  used  to  further 

Modifiers  define  or  describe  a  Class  Word.  When  used  in  a  data  element  name,  a  Class 

Word  Modifier  must  distinguish  one  data  element  from  another  and  normally 
will  narrow  the  range  of  allowable  values  established  by  the  Class  Word.  This 
Class  Modifier  is  taken  from  an  appropriate  data  model  entity  attribute. 

Example:  Vendor  Mailing-Address  City  Name 

In  this  example,  the  Class  Word  Modifier  City  is  modifying  the  Class  Word 
Name,  restricting  the  possible  range  of  values  for  the  data  element  to  names  of 
cities. 


Combining 
Prime  Word 
Modifiers  and 
Class  Word 
Modifiers 


When  Prime  Word  Modifiers  are  placed  after  the  Prime  Word,  or  Class  Word 
Modifiers,  or  a  combination  of  both,  the  total  number  of  these  components 
cannot  be  greater  than  4. 

Example:  Vendor  Headquarters  Mailing-Address  American  City  Name 


In  this  case,  there  are  2  Prime  Word  Modifiers  (Headquarters  and  Mailing- Address), 
and  there  are  2  Class  Word  Modifiers  (American  and  City). 


Qualifiers  Additional  modifiers,  called  qualifiers,  may  be  used  in  a  data  element  name  to 

further  categorize  a  Class  Word.  The  current  CG  data  element  naming  standard 
permits  the  use  of  qualifiers,  but  DoD  standards  do  not.  While  qualifiers  do  not 
define  the  structure  of  the  domain  of  the  class  word,  qualifiers  limit  the  types  of 
class  words  very  specifically. 

Example:  Vendor  Mailing-Address  City  Name  English 

The  word  “English”  specifies  that  the  city  names  for  Coast  Guard  vendors  we  are 
looking  for  are  only  in  English. 

NOTE:  DoD  data  standards  do  not  recognize  the  use  of  qualifiers  in  the  data 
element  naming  convention.  Therefore,  to  facilitate  data  sharing  with  DoD 
organizations,  fleet  logistics  data  element  names  should  avoid  use  of  qualifiers. 
The  information  described  by  the  qualifier  would  most  likely  be  described  in  the 
definition  of  the  data  element. 


Continued  on  next  page 
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4.2.4  Components  of  a  Data  Element  Name,  continued 


Review  The  following  is  a  summary  of  the  data  element  name  components  using  sample 

data  element  names: 


Modifier 
Preceding 
Prime  Word 

Prime  Word 

Modifier(s)  Following 

Prime  Word/  Class  Word 
Modifier(s) 

Class  Word 

Qualifier(s) 

Number 

0...1 

1 

0...4 

1 

L.2 

Presence 

Optional 

Required 

Optional 

B3SESSIH 

Example  1 
Example  2 
Example  3 

Coast-Guard 

Vendor 

Vessel 

Item 

Mailing-Address  City 

Type 

Name 

Code 

Temperature 

Celsius 

Standardize  Data  Elements 


4.2.5  Data  Element  Life  Cycle 


Introduction  Data  elements  evolve  through  a  series  of  standardization  phases.  Each  data 
element  submitted  for  standardization  are  assigned  one  of  the  following  status 
values  as  it  goes  through  the  approval  process:  developmental,  candidate, 
approved/disapproved,  installed,  modified,  archived.  The  changes  in  status 
mark  the  progress  of  a  data  element  through  its  life  cycle.  The  status  of  data 
elements  is  recorded  in  the  fleet  logistics  data  repository  as  one  of  the  attributes 
of  the  data  element. 


Stages  of  a  The  following  table  identifies  and  describes  each  of  the  stages  of  the  life  cycle  of 
Data  a  data  element.  These  stages  are  being  adopted  by  the  fleet  logistics  program. 

Element's  Life 
Cycle 


Stage 

Description 

Developmental 

This  status  is  assigned  to  a  data  element  which  is  under 
development  and  not  yet  ready  to  be  submitted  as  a  candidate.  At 
this  level,  it  will  not  be  considered  for  approval  by  either  the 
functional  or  technical  reviewers.  The  requirement  for  a  data 
element  is  normally  identified  during  data  modeling  or  through 
analyzing  new  functions,  such  as  those  precipitated  by  new 
legislation.  Data  elements  in  a  developmental  status  can  be 
entered  into  the  fleet  logistics  repository  for  coordination  and 
information  exchange  while  they  are  still  being  developed. 

Candidate 

This  status  is  assigned  to  a  data  element  that  has  been  fully 
developed  and  submitted  for  acceptance  as  a  standard  data 
element.  Candidate  data  elements  are  evaluated  by  the  assigned 
data  steward  and  by  fleet  logistics  DA  for  suitability  as  a  standard. 

Continued  on  next  page 
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4.2.5  Data  Element  Life  Cycle,  continued 


Stages  of  a  Data  Element’s  Life  Cycle  (continued) 


Stage 

Description 

Approval 

Approved  data  elements  can  exist  in  two  states:  approved,  and 
disapproved. 

Candidate  data  elements  that  pass  functional  and  technical  reviews 
become  approved.  Only  approved  data  elements  should  be  used  for 
development  of  information  systems. 

Data  elements  that  have  been  coordinated  through  the 
standardization  process  can  be  disapproved  for  the  following 
reasons: 

•  A  data  element  with  the  same  definition  already  exists. 

•  The  development  of  the  candidate  is  not  yet  complete. 

•  One  or  more  required  data  element  attributes  are  missing  or 
inappropriately  specified. 

Installed 

Fleet  logistics  configuration  management  (CM)  will  specify  an 
installation  date  for  each  approved  data  element  based  on  the 
recommendation  of  the  data  steward  assigned  to  that  data  element. 

As  of  the  installation  date: 

•  information  systems  must  accommodate  the  new  data  element 

•  organizations  authorized  to  supply  data  values  will  be 
responsible  for  entering  and  maintaining  the  standard  version  of 
the  data 

•  the  standard  data  element  will  be  used  to  support  information 
exchange  requirements 

Modified 

Approved  data  elements  that  are  currently  being  considered  for 
change  are  considered  modified  data  elements.  The  process  for 
approving  modifications  to  data  elements  is  identical  to  the  one  for 
approving  candidate  data  elements. 

Archived 

Installed  data  elements  are  archived  when  they  are  superseded  or  no 
longer  support  a  current  data  requirement.  The  elements  will  be 
used  for  cross  reference  purposes  and  to  assist  in  compiling  or 
recovering  information  that  spans  several  versions  of  the  fleet 
logistics  data  repository. 
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4.2.6.  Roles  And  Responsibilities  In  Standardizing  Data 
Eiements 


Introduction  This  subsection  provides  a  summary  of  the  roles  and  responsibilities  required  to 
perform  the  procedures  to  standardize  data  elements. 


Responsi-  The  major  responsibility  in  a  data  standardization  effort  belongs  to  the  system 

bilities  developer  and/or  system  maintainer.  The  system  developer  and/or  system 

maintainer’s  responsibility  is  to: 

•  Match  as  many  as  possible  of  an  application's  entities  and  data  element 
definitions  to  entities  and  data  elements  (entity  attributes)  in  the  fleet 
logistics  enterprise  data  model,  and  in  turn 

•  For  each  entity  attribute  found  in  the  enterprise  data  model  that  potentially 
matches  one  in  the  application,  the  system  developer  and/or  system 
maintainer  should  select  or  define  a  standard  data  element  definition  that  will 
be  used  in  the  system/application 

Doing  these  two  tasks  provides  the  following  two  benefits: 

1 .  The  work  to  standardize  the  small  number  of  data  elements  in  the  application 
not  found  in  the  data  model  is  manageable. 

2.  The  data  of  this  application  are  more  likely  to  be  shareable  and  useful  to  the 
organization  as  a  whole.  The  standard  data  element  definition  is  the  basic 
unit  for  data  sharing. 

The  following  table  lists  each  role,  identifies  the  responsibilities  of  that  role,  and 

indicates  the  procedures  detailing  those  responsibilities. 


Role 

Responsibility 

Procedure 

System  developer 
and  system 
maintainer 

Identifies  (from  approved  data  model)  entity 
attributes  for  which  matching  standard  data 
elements  are  needed.  Prepares  a  request  for  a  new 
data  element. 

Sections 

4.3.-4.5.1 

Data 

Administration 

Checks  completeness  and  quality  of  requests. 
Assigns  information  class  and  data  steward. 
Processes  a  request  for  a  new  data  element. 

Sections 

4.5.2  -  4.5.3 

Data  steward 

Verifies  necessity  and  uniqueness.  Assigns 
appropriate  subject  matter  expert. 

Sections 

4.5.2  -  4.5.3 

Subject  matter 
experts 

Verify  business  rules,  terms,  and  definitions. 

Sections 

4.5.2  -  4.5.3 
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4.2.7  The 


Introduction 


Process 

diagram 


Process  Of  Standardizing  Data  Elements 


The  stages  of  standardizing  a  data  element  are  identification,  standardization, 
approval,  and  integration.  This  process  ensures  that  the  data  element  is  unique 
and  in  compliance  with  the  procedures,  rules,  and  guidelines  outlined  in  this 
manual. 


The  following  diagram.  Figure  4-1: 

•  Depicts  the  activities  which  make  up  the  process  of  standardizing  data 
elements 

•  Notes  in  which  section(s)  in  this  manual  the  stage  of  development  is 
discussed 


4.2  iDENTIFiCATfON 


GATHERING  OF 
INFORMATION 
DESCRIBING  THE 
ENTITY 
ATTRIBUTE 


4,3  STANDARDIZATON 


DEFINING  AND 
ENSURING  THAT  THE 
DATA  ELEMENT 
COMPLIES  WITH 
PROCEDURES, 
RULES,  AND 
GUIDELINES 


4.4  APPROVAL 


REVIEWING  AND 
APPROVING  THE 
STANDARDIZED 
DATA  ELEMENT 


4.5  INTEGRATION, 
MAINTENANCE 


UPDATING  THE 
DATA  DICTIONARY 
WITH  THE 
APPROVED  DATA 
ELEMENT  AND 
MAINTAINING  THE 
DATA  ELEMENT 


Figure  4-1.  Phases  of  Data  Element  Life  Cycle 
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4.3  Identify  Data  Elements 


Introduction  This  subsection  describes  the  procedures  for  standardizing  data  elements.  Tasks 
within  these  procedures  are  performed  by  fleet  logistics  DA,  system  developers, 
system  maintainers,  data  stewards,  and  subject  matter  experts. 


Purpose  This  subsection  describes  the  procedures  to  be  used  when  data  elements  are 

being  considered  for  adoption  as  approved  standards. 


Contents  In  this  subsection  each  of  the  following  procedures  is  presented  in  detail. 


Title 

Section 

Develop  Standard  Data  Element 

4.3.1 

Identify  Data  Element  Requirements 

4.3.2 

Review  the  Data  Model  and  Data  Repository 

4.3.3 

Identify  and  Define  Data  Element  Attributes 

4.3.4 

Standardize  Data  Element  Name  and  Definition 

4.3.5 

Apply  the  Definition  Rules 

4.3.6 

Develop  Other  Attributes  of  a  Data  Element 

4.3.7 
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4.3.1  Develop  Standard  Data  Element 


Introduction  Requirements  for  data  are  identified  by  consumers  and  suppliers  of  information 
who  need  to  make  decisions  or  conduct  operations.  Systems  developers  who 
support  the  consumers  and  suppliers  may  also  identify  requirements  as  initial 
analysis  and  data  identification  progresses. 

The  data  elements  that  represent  data  requirements  are  not  developed  by  data 
administrators  or  by  business  operations  personnel  working  in  isolation.  Rather, 
they  are  developed  by  business  operations  people  working  together  with 
functional  experts  and  data  administrators  to  assist  in  defining  and  meeting  the 
data  requirements  of  the  business. 

A  review  of  standard  data  elements  in  the  fleet  logistics  DA  repository  and  the 
Coast  Guard  Data  Administration  Dictionary  System  (DADS)  can  often  result  in 
identification  of  a  data  element  which  already  meets  the  requirement  for  the 
system  under  development.  For  example,  it  may  be  discovered  that  the  original 
requirement  is  already  being  met  within  fleet  logistics,  and  the  development  task 
would  then  be  to  make  the  data  available  to  the  person  or  organization  needing  it 
at  the  time. 


It  is  the  intent  of  the  data  modeling  and  data  standardization  process  that  data 
standardization  should  begin  only  after  the  data  model  is  essentially  complete, 
and  that  the  standardization  process  should  only  be  in  the  context  of  the  data 
model.  After  the  set  of  data  elements  for  a  system  are  complete,  new  data 
elements  and  entities  should  be  integrated  into  the  data  model. 

Data  elements  named  within  the  context  of  the  fleet  logistics  DA  data  model  will 
facilitate  naming  data  elements,  help  avoid  duplication,  and  support  consistency 
throughout  Engineering  Logistics  and  the  DoD.  Refer  to  Sections  2.4, 
Architectural  Framework  for  Information  Systems  for  Fleet  Logistics,  and 
3.1,  Support  Integration  of  Data  Models,  for  more  information  on  data 
modeling  concepts  and  the  fleet  logistics  data  model. 


Standard  Requests  for  making  additions  to  the  data  repository  or  for  making  changes  to  an 

Request  Form  existing  data  element  are  submitted  on  Form  1 ,  Fleet  Logistics  Data  Element 

Request  (see  Appendix  D,  Section  D.l,  Data  Element  Development  Worksheet 
and  Data  Element  Request,  and  Section  6,  Implement  Metadata  Repository,  for 
more  information  on  the  data  repository). 


Fleet 
Logistics 
Data  Models 


Continued  on  next  page 
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4.3.1 


Roles 


Process 


Develop  Standard  Data  Element,  Continued 


Because  the  system  developer  and/or  system  maintainer  has  the  primary 
responsibility  for  requesting  additions  or  changes  to  data  elements,  the  system 
developer  and/or  system  maintainer  is  responsible  for  completing  the  Standard 
Data  Element  Request  Form  (see  Section  4.3.3.,  Review  the  Data  Model  and 
Data  Repository)  and  for  submitting  it  to  fleet  logistics  DA  for  validation  and 
processing.  The  criteria  for  reviewing  data  element  requests  are  provided  in 
Section  8.  If  there  are  problems  with  the  form,  fleet  logistics  DA  will  return  it  to 
the  system  developer  and/or  system  maintainer  for  correction,  completion,  and 
re-submittal. 


The  process  of  creating  a  request  to  add  or  change  a  data  element  has  the 
following  four  steps: 


Step 

Action 

See  Section: 

1 

Identify  Data  Element  Requirements 

4.3.2 

2 

Review  the  Fleet  Logistics  Data  Model  and 
Metadata  Repository 

4.3.3 

3 

Identify  and  Define  Data  Element  Attributes 

Appendix  C 

4 

Verify  Data  Element  Name  and  Definition 

4.2.4 
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4.3.2  identify  Data  Element  Requirements 


Introduction  Before  developing  standard  data  elements  for  a  new  system,  it  is  helpful  to  have 
a  complete  understanding  of  the  data  requirement  for  each  data  element.  To  gain 
this  understanding,  a  data  element  developer  should  gather  all  available 
documentation  that  may  provide  information  for,  or  assist  in,  initially  identifying 
data  elements  for  a  system  under  development,  as  described  in  the  topics  below. 


Data  Element  When  gathering  information  for  data  element  development,  use  the  Data  Element 
Development  Development  Worksheet  (see  Appendix  D,  Section  D.l,  Data  Element 
Worksheet  Development  Worksheet  and  Data  Element  Request,  for  a  facsimile  of  the 
Data  Element  Development  Worksheet).  This  worksheet  is  almost  identical  to 
the  Data  Element  Request  Form,  and  helps  to  record  and  organize  data  item 
findings  as  during  the  Data  Element  development  process. 


Reference  Appropriate  references  and  resources  include  the  following: 

Material 

•  Functional  information  resources  that  might  exist 

•  Functional  data  models  and  process  models  that  might  exist 

•  Functional  data  dictionaries  that  might  exist 

•  Federal  Information  Processing  Standards  (FIPS) 

•  "Dictionary  of  Business  Terms" 

•  An  unabridged  dictionary 

•  U.S.  Military  Dictionary  (Dictionary  of  Military  Terms/ Acronyms) 

•  Coast  Guard  application  dictionaries  that  may  exist 

•  Roget's  Thesaurus 

•  Notes  from  interviews  with  business  and  systems  analysts 

•  Coast  Guard  Publications,  Manuals,  Directives  and/or  Instructions 

•  System  documentation 

•  Technical  writing  guides 


Continued  on  next  page 
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4.3.2  Identify  Data  Element  Requirements,  Continued 


How  to  Follow  the  steps  in  the  table  below  to  identify  data  element  requirements. 

identify  Data 

Element 

Requirements 


Step 

Action 

1 

Document  the  need  for  data  elements  discovered  in  any  of  the  sources 
named  above.  Record  any  existing  names,  codes,  definitions,  field 
lengths,  data  value  names,  sources  of  data,  and  other  relevant 
information.  This  information  provides  a  knowledge  base  to  be  used  in 
defining  and  constructing  individual  data  elements. 

2 

Analyze  requirements  documentation  to  understand  the  way  the 
information  will  be  used  in  a  proposed  system.  Functional  descriptions 
also  contain  information  requirements. 

3 

Analyze  existing  information  system  documentation  to  weed  out 
impertinent  data  and  to  determine  the  fundamental  data  requirement. 

4 

Determine  data  requirements  by  separating  any  usage  information  from 
the  data  and  determine  the  fundamental  data  element  to  be  constructed. 

Sources  of  The  need  for  new  data  elements  may  be  discovered  during; 

Requirements 

for  Data  •  Information  system  development 

Elements 

•  Various  phases  of  information  engineering  (e.g.,  during  the  construction  of 
functional  data  models) 


•  Examination  of  existing  related  data  dictionaries,  functional  publications, 
data  element  descriptions,  system  documentation,  systems  specifications, 
existing  databases,  reports,  forms,  user  manuals,  and  other  data  stores 


Continued  on  next  page 
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4.3.2  Identify  Data  Element  Requirements,  Continued 


How  to  Follow  the  steps  in  the  table  below  to  research  data  elements  with  the  goal  of 

Research  separating  the  identity  of  the  data  (what  it  is)  from  its  application/system  (how  it 

Data  Element  is  used).  This  is  a  fundamental  goal  of  data  standardization. 

Requirements 


Step 

Action 

1 

Develop  a  well  bounded  domain  definition  and,  if  required,  a 
comprehensive  list  of  data  values  for  the  data  element  to  be  developed. 

This  domain  definition  will  act  as  the  working  definition  for  data  element 
development.  In  the  subsequent  steps  of  data  standardization,  the 
developer  may  find  the  need  to  refine  this  working  definition. 

When  determining  the  domain  definition,  bear  in  mind  that  the  data 
element  definition  should: 

a.  have  one  single  meaning 

b.  have  homogenous  and  exclusive  values 

c.  not  have  any  codes  that  are  themselves  confusing 

2 

Examine  documentation  sources  for  definition  and  data  value 
information. 

3 

Identify  the  scope  of  the  data  element  from  functional  regulations  or 
directives. 

4 

Interview  any  available  functional/subject  matter  experts  for  detailed 
information  needed  to  develop  standard  data  elements. 

Upon  Upon  completion  of  the  above  steps  continue  with  the  next  the  procedure, 

Completion  Review  the  Data  Model  and  Data  Repository  (Section  4.33). 
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4.3.3  Review  the  Data  Model  and  Data  Repository 


Introduction  Once  the  developer  has  gathered  the  data  element  requirements  for  system 

development,  s/he  review  the  fleet  logistics  enterprise  data  model  to  determine 
where  there  are  matches  between: 

•  the  data  requirements  and  the  data  entity  attributes  in  the  data  model 

•  the  data  requirements  and  the  existing  data  elements  in  the  metadata 
repository 

If  other  systems  have  been  developed  using  the  fleet  logistics  DA  methodology 
described  in  this  manual,  a  review  of  the  fleet  logistics  metadata  repository 
should  result  in  finding  most  of  the  standard  data  elements  that  will  be  required 
by  the  new  system.  The  developer  will  need  to  propose  new  standard  data 
elements  for  any  data  requirements  that  s/he  has  identified  that  do  not  have  a 
matching  standard  data  element  in  the  repository  (refer  to  Sections  4.3.4  through 
4.3.7  for  more  details  on  creating  data  element  names  and  sending  them  through 
the  approval  process). 


Procedures  To  determine  the  existence  of  standard  data  elements  to  use  for  a  new  system, 
for  Reviewing  perform  the  following  steps.  The  criteria  for  assessing  the  quality  of  a  data 
the  Data  model  are  provided  in  Section  8,  Ensure  Data  Quality. 

Model  and 

Metadata 

Repository 


Step 

Action 

1 

Perform  a  systematic  search  through  the  entire  fleet  logistics  data  model 
to  identify  data  entity  attributes. 

2 

Determine  which  entity  attributes  have  already  been  developed  into 
standard  data  elements  by  checking  the  fleet  logistics  data  repository 
(check  all  candidate,  approved,  installed,  and  archived  data  elements). 
The  remaining  (probably  few)  attributes  may  be  mis-defined,  require 
more  information,  or  may  be  candidates  for  requesting  new  or  modified 
standard  data  elements. 

3 

Using  the  data  requirements  determined  in  Section  43.2,  create  standard 
data  elements  for  any  remaining  data  items,  using  the  procedures 
described  in  Sections  4.3.4  through  4.3.7  (refer  to  the  DoD  and/or  other 
Federal  repositories  for  help  in  creating  data  elements  that  are  not  yet 
part  of  the  fleet  logistics  standard). 

Continued  on  next  page 
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4.3.2  Identify  Data  Element  Requirements  and  Data 
Repository,  continued 


Procedures  for  reviewing  data  model  and  data  repository  (continued) 


4 

Compare  the  standard  data  elements  found  in  the  fleet  logistics  data 
repository  to  the  application’s  information  requirements.  Match  as  many 
data  requirements  to  standard  data  elements  as  possible. 

If  a  standard  data  element  is  found  that  for  the  most  part  matches  the  data 
element  identified  for  the  local  application,  note  that  standard  data 
element  for  use  in  the  new  application  system  and  discard  the  locally 
created  data  element. 

If  there  are  some  attributes  that  should  be  modified  in  or  added  to  the 
standard  data  element  found  through  the  current  effort,  refer  to  the 
procedures  discussed  in  Section  4.5,  Maintain  Data  Elements. 

5 

If  analysis  does  not  identify  a  fleet  logistics  standard  data  element  that 
matches  the  data  element  created  from  the  set  of  application  data 
requirements,  submit  that  data  element  as  a  developmental  candidate  as 
described  in  the  procedures  in  Section  4.4,  Procedures  to  Approve  Data 
Elements.  Again,  after  the  development  and  registration  of  the  initial 
standard  fleet  logistics  systems,  any  new  application’s  list  of  unique  data 
element  candidates  should  be  relatively  small. 
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4.3.4  Identify  and  Define  Data  Element  Attributes 


Introduction  This  subsection  discusses  the  procedures  for  creating  and  defining  data  element 
components.  Topics  include: 

•  Class  Word  and  Definition 

•  Class  Word  Modifier 

•  Prime  Word  and  Definition 

•  Prime  Word  Modifier(s) 

•  Qualifiers 

•  Other  Attributes 

When  creating  a  data  element,  follow  the  topics  below  in  the  order  that  they 
appear.  Subsection  4.2.4,  Components  of  a  Data  Element  Name,  identifies 
and  describes  the  various  parts  of  the  name  of  a  data  element  that  are  referred  to 
below. 


Identify  the  A  class  word  defines  the  general  category  of  data  that  is  stored  in  a  data  element. 
Class  Word  In  To  identify  the  class  word,  follow  the  steps  below; 

the  Data 
Element 
Name 


Step 

Action 

1 

Using  the  working  domain  definition  developed  in  Section  4.3.2,  identify 
the  category  of  data  {class  word)  associated  with  the  entity  attribute  for 
which  the  data  element  is  being  developed  (e.g.,  code,  name,  or  amount). 
This  will  come  from  the  class  word  name  list  in  Appendix  B,  Class 

Word  Descriptions. 

2 

If  you  are  not  able  to  identify  the  appropriate  class  name,  pick  the  one 
that  comes  closest,  or  request  assistance  from  fleet  logistics  DA. 

Example  of  For  example,  in  the  case  where  it  is  more  convenient  to  use  the  numbers  1 

Class  Word  through  12  to  represent  the  months,  the  class  word  would  be  code,  a 

Name  combination  of  one  or  more  numbers  substituted  for  a  specific  meaning. 


Continued  on  next  page 
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4.3.4  Identify  and  Define  Data  Element  Attributes,  Continued 


Identify  Class  The  addition  of  modifiers  to  further  describe  and  restrict  the  category  of  data  to 
Word  Modifier  be  collected  is  optional.  A  maximum  of  1  modifier  is  allowed.  If  a  class  word 
modifier  is  necessary,  the  system  developer  and/or  system  maintainer  should 
reference  the  entity  attribute  designation. 

Combine  the  class  word  modifier  and  the  selected  class  word  to  form  the  generic 
element  name. 

Refer  to  Section  4.2.4,  Components  of  a  Data  Element  Name,  items  Prime 
Word  Modifiers  and  Class  Word  Modifier  for  a  discussion  of  the  rules  for 
combining  modifiers  within  a  Data  Element  Name. 


Example  of  For  the  class  word  code  in  the  above  example,  month  would  be  an  appropriate 

Generic  modifier.  Hence,  the  fully  described  generic  element  name  would  be  month 

Element  code. 

Name 


Modify  Begin  by  refining  the  domain  definition  defined  in  Section  4.3.2  into  a  narrative 

Domain  statement  using  the  class  word  and/or  modifiers  (generic  element)  just  selected. 

Definition 

The  structure  of  the  definition  of  a  data  element  is  described  by  its  associated 
generic  element  name.  CG  data  standards  require  that  the  class  word  appears  in 
the  data  element  definition.  With  these  two  things  in  mind,  an  easy  way  to  begin 
wording  a  data  element  definition  is  to  start  the  definition  with  a  phrase 
describing  the  class  word.  The  table  in  the  topic  below.  Definition  Beginnings, 
lists  in  alphabetical  order  the  class  word  name  and  a  suggested  phrase  that  would 
begin  its  associated  data  element’s  definition. 

The  class  word  modifiers  found  within  the  definition  structure  represents 
optional  words  that  can  be  incorporated  to  clarify  the  data  element's  definition 
and  further  distinguish  it  from  another  similar  data  element. 


The  Generic  Make  modifications  to  the  generic  element  definition  structure  by  refining  the 
Element  domain  definition  of  the  data  element  as  follows: 

Definition 

Structure 


Continued  on  next  page 
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4.3.4  Identify  and  Define  Data  Element  Attributes,  Continued 


The  Generic  Element  Definition  Structure  (continued) 


Step 

Action 

1 

Select  the  beginning  of  the  definition  from  the  table  below  in  the  topic 
Definition  Beginnings. 

2 

Formulate  a  definition  for  the  class  word  and  modifiers. 

3 

Make  the  definition  a  logically  sequenced,  grammatically  and 
structurally  correct,  simple  sentence  definition. 

4 

Edit  and  refine  the  generic  element  name  according  to  acceptable 

English  writing  conventions  and  the  definition  rules  described  in  Section 
4.3,6. 

Definition  The  following  list  of  definition  beginnings  is  found  in  Appendix  A  of  the  DoD 

Beginnings  Data  Element  Standardization  Procedures y  DoD  8320J-M-1 ,  January;  1993. 


If  the  class  name  is... 

then  begin  the  definition  with... 

AMOUNT 

The  (modifiers)  amount  of ... 

ANGLE 

The  (modifiers)  angle  between  ...  for  a  ... 

AREA 

The  (modifiers)  area  measurement  of ... 

CODE 

The  (modifiers)  code  that  represents/denotes  a  ... 

COORDINATE 

The  coordinate  identifying  the  (modifiers)  location  of ... 

DATE 

The  (modifiers)  date  of  /when/on  which/  a ... 

DIMENSION 

The  (modifiers)  dimension  of/from  ... 

MASS 

The  (modifiers)  mass  of ... 

NAME 

The  (modifiers)  name  that  designates  ... 

NUMBER 

The  (modifiers)  number  assigned  to  represent ... 

QUANTITY 

The  (modifiers)  quantity  of ... 

RATE 

The  rate  of  (force,  speed,  pay,  etc.,)  of .... 

TEMPERATURE 

The  temperature  of ... 

TEXT 

Text  that  (describes/defines) .... 

TIME 

The  (modifiers)  time  that  designates  the  occurrence  of ... 

VOLUME 

The  (modifiers)  volume  of ... 

WEIGHT 

The  (modifiers)  weight  of ... 

Continued  on  next  page 
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4.3.4  Identify  and  Define  Data  Element  Attributes,  Continued 


Qualifiers 


The  following  steps  should  be  followed  when  adding  a  qualifier  to  a  data  element 
name. 


Step 

Action 

1 

Add  the  qualifier  to  the  generic  element  name. 

2 

Refine  the  working  definition  for  the  generic  element  by  adding  a 
representation  of  the  qualifier  to  the  end  of  the  generic  element 
definition.  For  example,  The  temperature  in  Celsius  of... 

3 

Make  the  definition  a  logically  sequenced,  grammatically  and 
structurally  correct,  simple  sentence  definition. 

4 

Edit  and  refine  the  definition  according  to  acceptable  English  writing 
conventions. 

Prime  Word  Follow  the  steps  below  to  select  the  prime  word  for  the  data  element  under 
Name  development. 


Step 

Action 

1 

From  the  fleet  logistics  data  model  identify  the  entity  that  is  appropriate 
for  the  data  element  being  developed.  Note  that  the  data  element  will  be 
equivalent  to  the  entity  attribute. 

2 

Record  the  entity  name  as  the  prime  word  name  for  this  data  element. 

Example  of  Assume  that  a  system  developer  and/or  system  maintainer  is  creating  a  data 
Prime  Word  element  for  the  “name  of  a  vehicle.”  Looking  at  the  fleet  logistics  Data  Model, 
the  developer  finds  a  data  entity  called  vehicle.  The  system  developer  would 
choose  the  data  entity  name  vehicle  as  the  prime  word  to  go  with  the  class  word 
name.  The  result  would  be  the  selected  prime  word  and  class  word  components 
forming  the  data  element  name  vehicle  name. 

One  way  to  search  for  the  appropriate  prime  word  in  a  data  model  is  to  bear  in 
mind  that  the  prime  word  represents  the  logical  grouping  (data  entity)  in  the 
model  to  which  the  data  element  (and  associated  data  entity  attribute)  belongs. 


Continued  on  next  page 
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4.3.4  Identify  and  Define  Data  Element  Attributes,  continued 


Prime  Word  &  Prime  Word  modifiers  may  be  added  to  further  describe  the  prime  word  for  this 
Modifier  data  element.  When  used,  up  to  4  prime  word  modifiers  are  allowed,  but  try  to 

Name  keep  them  to  a  minimum  so  as  to  be  as  precise  and  unique  as  possible.  The 

modifiers  can  be  selected  from  the  list  of  entity  names  in  the  data  model  that 
either  represent  up  to  two  levels  higher  than  the  prime  word/data  entity,  or  that 
represent  a  sub-entity. 

Refer  to  Section  4.2.4,  Components  of  a  Data  Element  Name,  for  a  discussion 
of  the  rules  for  combining  modifiers  within  a  Data  Element  Name,  and  for 
developing  the  modifiers. 


Example  of 
Prime  Word 
and  Modifier 
Name 


Using  the  example  from  above  in  discussing  the  Prime  Word,  the  system 
developer  and/or  system  maintainer  may  determine  that  the  prime  word  vehicle 
may  not  fully  describe  the  object  being  categorized.  If  this  were  the  case,  the 
system  developer  and/or  system  maintainer  may  find  a  higher  level  entity  or  sub¬ 
entity  and  use  it  as  a  modifier.  In  this  case,  the  system  developer  and/or  system 
maintainer  might  come  up  with  land  vehicle  name  as  the  data  element  name. 


Definition  of  The  following  steps  are  to  be  followed  to  develop  the  definition. 

Prime  Word 
and  Modifiers 


Step 

Action 

1 

Review  the  definitions  of  the  entity  in  the  source  data  model  and  the 
associated  attribute  for  which  the  data  element  is  being  developed  and 
relate  it  to  the  fleet  logistics  data  model. 

2 

Formulate  a  definition  for  the  prime  word  with  its  modifier(s). 

3 

Make  the  definition  a  logically  sequenced,  grammatically  and 
structurally  correct,  simple  sentence. 

4 

Edit  and  refine  the  definition  according  to  the  standards  of  English 
writing,  and  apply  the  definition  rules  as  described  in  Section  4.3.6. 

Continued  on  next  page 
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4.3.4  Identify  and  Define  Data  Element  Attributes,  Continued 


Upon  When  the  above  steps  have  been  completed  for  defining  the  components  of  the 

Completion  Data  Element  Name,  proceed  to  the  next  Section,  4.3,5,  Standardize  Data 
Element  Name  and  Definition. 
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4.3.5 


Standardize  Data  Element  Name  And  Definition 


Standardize 
the  Data 
Element 
Name 


Now  that  all  of  the  components  of  the  data  element  name  have  been  identified 
and  defined,  follow  the  steps  in  the  table  below  to  combine  them  into  a  data 
element  name  meets  standardization  guidelines. 


Step 

Action 

1 

Draft  the  full  name  of  the  data  element  using  the 

•  class  word  and  modifier  (generic  element  name),  and  qualifier 

•  prime  word  and  modifier(s) 

as  developed  in  the  above  procedures. 

2 

Apply  the  following  rules  to  standardize  the  full  name  of  the  data 
element. 

Note:  The  following  rules  are  based  on  rules  found  in  DOD’s  Standard 
Data  Element  Development,  Approval,  and  Maintenance 

Procedures  Manual  8320.1-M-l  (May  1992). 

The  full  name  of  a  data  element: 

•  will  contain  one  class  word 

•  will  contain  one  prime  word 

•  will  describe  only  one  concept 

•  will  be  unique  across  all  standardized  data  element  names 

•  should  not  contain  plurals  of  class  word  or  prime  word 

•  will  use  modifiers  to  clarify  the  name 

•  must  consist  of  alphabetic  characters  (A-Z) 

Exception:  Numbers  (0-9)  may  be  used  when  part  of  a  descriptive 
name 

Exception:  Hyphens  are  permitted  for  generally  accepted 
hyphenated  words  (e.g.,  in-house,  follow-up) 

•  should  not  contain  names  of 

-  organizations 

“  computer  or  information  systems 

-  directives 

-  forms 

-  screens 

-  reports 

•  should  not  contain  titles  of  blocks,  rows,  or  columns  of  screens, 
reports,  or  listings 

•  should  not  contain  abbreviations  or  acronyms  unless  the  data 
element's  full  name  exceeds  250  characters 

Continued  on  next  page 
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4.3.5  Standardize  Data  Element  Name  And  Definition,  Continued 


Upon  Completion  (continued) 


3 


If  the  full  data  element  name  exceeds  250  characters,  use  the  following 
procedure  to  standardize  the  name. 


Reference:  For  lists  of  abbreviations  and  detailed  rules  on  how  to 
abbreviate  a  data  element's  full  name,  see  Section  4.3.4,  Identify  and 
Define  Data  Element  Attributes,  item  Rules  for  Abbreviating  Words.. 


Note:  If  after  following  the  procedures  below  the  full  name  still 
exceeds  250  characters,  then  contact  fleet  logistics  DA. 


If... 

then  incorporate  the 
abbreviation  of  the... 

a  common  business  term  exists 
in  the  data  element's  full  name 

common  business  term 

the  full  name  still  exceeds  250 
characters 

class  word 

the  full  name  still  exceeds  250 
characters 

prime  word 

the  full  name  still  exceeds  250 
characters 

modifiers 

Definition  Apply  the  definition  rules,  found  in  Sections  4.3.6  and  4.3.7,  Apply  the 

Rules  Definition  and  Abbreviation  Rules,  to  assure  uniformity,  consistency,  and 

intelligibility. 
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4.3.6.  Apply  the  Definition  Rules 


Introduction  The  final  step  in  developing  a  definition  text  for  a  data  element  is  to  verify  that 
the  definition  complies  with  the  definition  rules. 

The  following  definition  rules  are  based  on  rules  found  in  DOD's  Standard  Data 
Element  Development,  Approval,  and  Maintenance  Procedures  Manual  8320.1  - 
M-1  (May,  1992).  Changes  or  additions  to  this  list  must  be  forwarded  to  fleet 
logistics  DA  for  approval. 


Standardize  Edit  and  refine  the  definition  of  the  data  element  to  comply  with  the  following 

the  Definition  rules: 

•  The  definition  must  explain  WHAT  the  data  is.  The  definition  does  not 
explain  HOW,  WHERE,  or  WHEN,  it  is  used,  or  WHO  uses  it. 

•  The  data  element  name  must  not  be  repeated  verbatim  in  its  own  definition, 
although  the  words  within  the  name  are  incorporated  within  the  definition  (the 
class  word  MUST  be  in  the  definition) 

•  The  definition  must  have  one  and  only  one  interpretation.  The  definition 
must  not  be  ambiguous. 

•  The  definition  must  be  written  in  language  common  to  all  users  within  the 
organization. 

•  The  definition  must  not  contain  acronyms  or  abbreviations. 

•  The  definition  should  not  contain  processing  or  editing  instructions. 

•  The  definition  should  not  refer  to  hardware,  software,  or  language 
conventions  or  constraints. 

•  When  the  definition  is  imposed  by  an  external  source,  that  source  must  be 
included  in  the  definition. 
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4.3.7.  Develop  Other  Attributes  of  a  Data  Element 


Introduction  In  order  to  complete  the  standardization  of  a  data  element,  the  system  developer 
and/or  system  maintainer  must  develop  the  other  data  element  attributes  in 
addition  to  the  definition. 

Other  Attribute  values  should  be  recorded  for  each  of  the  remaining  attributes  for  a  data 

Attributes  element.  Refer  to  the  detailed  standard  data  element  attribute  descriptions  in 

Appendix  C,  Data  Element  Attribute  Descriptions. 

Abbreviations  Abbreviations  are  used  in  the  data  element  name  components  to; 

•  Develop  a  data  element's  ten  character  abbreviated  name 

•  Shorten  a  data  element's  full  name  to  comply  with  the  250  character  limit. 


The  rules  for  developing  abbreviations  for  words  include  the  following: 

•  The  abbreviation  of  a  modifier  should  begin  with  the  first  letter  of  the  word. 

•  The  order  of  characters  in  the  abbreviation  should  parallel  the  order  of  the 
letters  in  the  word. 

•  The  abbreviation  of  a  word  is  generally  created  by  removing: 

—  vowels  (except  the  first  letter  of  a  word) 

—  double  consonants  from  fully  spelled  words. 

•  Use  commonly  accepted  abbreviations  in  their  customary  form. 

Note:  These  rules  are  based  on  rules  found  in  DOD’s  Standard  Data  Element 
Development,  Approval,  and  Maintenance  Procedures  Manual,  8320. 1  -M-1 . 

May  1992. 

After  all  the  data  element  attributes  have  been  determined  for  a  new  data  element 
that  does  not  appear  in  the  fleet  logistics  data  repository,  submit  the  set  of  data 
element  attributes  into  the  approval  process.  Section  4.4,  Procedures  to 
Approve  Data  Elements,  covers  the  submission  and  approval  processes. 


Upon 

Completion 


Rules  for 

Abbreviating 

Words 
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4.4  Procedures  To  Approve  Data  Elements 


Introduction  This  subsection  describes  the  procedures  to  be  used  when  data  elements  are 

being  considered  for  adoption  as  approved  standards.  The  purpose  of  this  section 
is  to  provide  the 

•  details  for  submitting  the  Data  Element  Request  Form 

•  procedures  for  approving  or  disapproving  the  Request. 

Refer  to  Appendix  D,  section  D.l,  for  a  facsimile  of  the  Data  Element  Request 
Form. 


In  this  The  following  topics  are  covered  in  this  section: 

Subsection 


Topic 

See 

Submit  the  Data  Element  Request 

4.4.1 

Preliminary  Review 

4.4.2 

Formal  Review 

4.4.3 
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4.4.1  Submit  the  Fleet  Logistics  Data  Element  Request 


When  to 
follow  this 
procedure 


After  the  identification  process  has  been  completed,  the  data  element  must  be 
documented  and  submitted  for  approval.  This  includes  documentation  of  the 
element's  attributes  and  of  administrative  information. 


Review  and  Follow  the  steps  in  the  table  below  to  fill  out  and  process  the  request  form. 

Submit 

Request 


Step 

Action 

1 

Complete  the  Fleet  Logistics  Data  Element  Request  form.  Refer  to 
Section  4.3,  Procedures  to  Standardize  Data  Elements,  for  detailed 
instructions  for  each  entry  on  the  form. 

2 

Review  all  the  data  entered  on  the  Fleet  Logistics  Data  Element  Request 
Form  to  ensure  compliance  with  the  rules  and  procedures  described  in 
Section  4.3  before  submitting  the  Request.  Discuss  the  data  element 
with  counterparts  in  the  functional  areas  before  submitting  the  Request. 

Refer  to  Sections  8.3, 8.6,  and  8.7  for  a  discussion  and  procedures  for 
ensuring  data  quality  when  reviewing  data  elements. 

3 

Submit  the  form  to: 

Fleet  Logistics  DA 

USCG  Headquarters 

G-ELC 
[mail  address] 

4 

If  acknowledgment  of  receipt  by  fleet  logistics  DA  is  not  received  within 

5  business  days,  contact  fleet  logistics  DA  to  ascertain  whether  a 
resubmittal  is  required.  If  so,  resubmit  a  copy  of  the  original  request. 

Upon 

completion 


When  the  above  steps  have  been  completed,  perform  the  procedure  described  in 

Section  4.4.2,  Preliminary  Review. 
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4.4.2  Preliminary  Review 


Introduction 

Developmental  data  elements  will  be  reviewed  in  accordance  with  procedures  for 
adherence  to  technical  and  functional  requirements  before  being  considered  as  a 
candidate  or  modified  standard  data  element. 

Roles 

Fleet  logistics  DA  and  the  data  stewards  have  the  responsibility  to  validate  the 
completeness  of  the  request  form  and  to  verify  that  the  contents  comply  with  the 
standards  and  with  all  functional  requirements.  If  there  are  problems  with  the 
form,  the  DA  will  return  it  to  the  system  developer  and/or  system  maintainer  for 
correction,  completion,  and  re-submittal. 

Procedure 

Follow  the  steps  in  the  table  below  to  verify  the  validity  of  a  request. 

Step 

Action 

1 

Review  developmental  data  elements  for  adherence  to  the  following 

technical  and  functional  requirements: 

•  The  data  element  requirement  must  be  derived  from  an  approved 
data  model. 

•  The  definition  of  the  data  element  must  fully  describe  the  data 
requirement  and  convey  only  one  concept. 

•  The  data  element  name  must  conform  to  the  data  element  naming 
standards  described  in  Section  4.3. 

•  The  mandatory  data  element  attributes  must  be  fully  described. 

•  The  class  word  name  associated  with  the  data  element  must  be  an 
approved  class  word. 

Refer  to  Sections  8.3, 8.6,  and  8.7  for  a  discussion  and  procedures  for 

ensuring  data  quality  when  reviewing  data  elements. 

2 

Return  to  the  originator  any  data  element  that  does  not  meet  the  criteria 
in  Section  4.3  with  the  reason(s)  for  the  rejection. 

3 

For  data  elements  that  meet  the  criteria: 

•  Confirm  that  a  suitable  data  element  does  not  already  exist  by 
reviewing  all  standard  data  elements  in  the  repository  that  have  the 
same  or  similar  names  or  descriptions.  (This  includes  archived 
standard  data  elements.) 

•  If  the  data  element  attributes  are  identical  or  similar  to  a  standard 
data  element  in  the  repository,  return  the  developmental  or  modified 
data  element  to  the  originator  for  further  review  of  existing  standard 
data  elements. 

Continued  on  next  page 
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4.4.2  Preliminary  Review,  Continued 


Procedure  (continued) 


Step 

Action 

4 

As  discussed  in  section  3.4,  Receive  and  Evaluate  Data  Model,  submit 
developmental  or  modified  data  elements  to  fleet  logistics  DA  for  a 
review  of  the  metadata  repository  for  the  existence  of  any  similar,  usable 
data  elements. 

5 

Enter  the  validated  developmental  data  element  into  the  repository  as  a 
candidate  or  modified  standard  data  element  to  begin  the  approval 
process.  The  designated  data  steward  of  each  of  the  candidate  standard 
data  elements  and  the  fleet  logistics  DA  will  be  notified  that  new 
candidate  or  modified  standard  elements  are  awaiting  their  review. 
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4.4.3  Formal  Review 


Introduction  Fleet  logistics  DA  and  the  data  steward  of  the  candidate  or  modified  data  element 
must  approve  or  disapprove  the  data  element  within  1 0  workdays  of  notification 
that  the  candidate  data  element  has  been  submitted  for  review.  Requests  for  time 
waivers  must  be  sent  to  fleet  logistics  DA  with  reason  why  more  time  is  required, 
fleet  logistics  DA  will  allow  a  minimum  of  7  workdays  before  approving  a  data 
element  to  permit  adequate  time  to  review  and  comment  on  the  data  element. 


Review  Fleet  logistics  DA  and  the  designated  data  steward  will  conduct  concurrent 

Procedures  reviews  of  candidate  standard  elements  as  described  in  the  table  below. 


Step 

Responsibility 

Action 

1 

Fleet  Logistics  DA 

Reviews  the  candidate  or  modified  data  element 
within  10  workdays  and  determines  that  the 
candidate  standard  data  element  conforms  to 
fleet  logistics  DA  policy  and  does  not  conflict 
with  existing  standard  data  elements. 

2 

Fleet  Logistics  DA 

Reviews  the  data  element  attributes  for 
completeness  and  conformance  with  current 
technical  requirements. 

3 

Fleet  Logistics  DA 

Validates  the  data  element  by  confirming 
conformance  to  the  fleet  logistics  data  model. 

4 

Fleet  Logistics  DA 

Provides  reason  for  either  approval  or 
disapproval  of  data  element  in  the  Standard  Data 
Element  Review  Comment  Text  field  attribute  for 
the  data  element  (see  Appendix  D  for  more 
information  on  this  and  the  other  data  element 
attributes).  Disapproved  data  elements  need  to 
be  resolved  by  the  designated  data  steward. 

Continued  on  next  page 
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4.4.3  Formal  Review,  Continued 


Review  Procedures  (continued) 


Step 

Action 

5 

Data  Steward 

•  Reviews  the  candidate  or  modified  standard 
data  element  within  20  workdays  for 
consistency  within  the  functional  area  and 
for  conformance  with  cross-functional 
integration  requirements. 

•  Validates  the  data  element  attributes  to 
ensure  that  the  data  element  is  functionally 
accurate  and  complete. 

•  If  the  data  steward  believes  that  some  other 
data  steward  should  be  responsible  for  the 
data  element,  that  change  will  be  made  and  a 
comment  explaining  the  rationale  will  be 
provided.  The  20  day  review  period  begins 
again  any  time  the  data  steward  is  changed. 

6 

Data  Steward 

•  Coordinates  with  appropriate  subject  matter 
experts  to  ensure  that  the  data  element  will 
meet  all  functional  data  requirements. 

•  Coordinates  efforts  to  resolve  any  technical 
deficiencies. 

•  Must  review  the  functional  area  data  model 
and  assess  the  impact  of  the  new  data 
element. 

•  If  another  data  steward  believes  that  the  data 
steward  designation  was  incorrectly  made,  a 
comment  should  be  immediately  generated 
to  the  assigned  data  steward  and  to  fleet 
logistics  DA  for  resolution. 

Continued  on  next  page 
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4.4.3  Formal  Review,  Continued 


Review  Procedures  (continued) 


Step 

Action 

7 

Data  Steward 

Must  coordinate  modified  standard  data  elements 
with  the  other  data  stewards  and  functional 
counterparts  who  will  be  affected  by  the  change 
to  the  existing  data  element.  Users  of  the 
existing  standard  data  element  are  indicated  by 
the  information  systems  registered  in  the 
repository  as  applications  of  the  standard  data 
element. 

8 

Data  Steward 

May  still  elect  to  approve  the  data  element  even 
if  concurrence  is  not  obtained  from  all 
respondents.  All  non-concurrences  must  be 
noted  in  the  repository  for  review  by  fleet 
logistics  DA. 

9 

Data  Steward 

Notifies  fleet  logistics  DA  by  annotating  the 
reasons  for  rejection  in  the  repository  if  s/he 
determines  that  the  data  element  is  not  consistent 
with  or  conflicts  with,  existing  standard  or 
modified  data  elements  within  the  functional 

area. 

10 

Data  Steward 

Recommends  approval  of  the  data  element  if  no 
conflicts  exist.  Notifies  fleet  logistics  DA  by 
annotating  the  approval  in  comments  on  the  data 
element  in  the  repository. 

Continued  on  next  page 


4-43 


standardize  Data  Elements 


4.4.3  Formal  Review,  Continued 


Review  Procedures  ( continued) 


Step 

Action 

11 

Fleet  Logistics  DA 

•  Evaluates  the  recommendations  from  the 
technical  and  functional  reviews  and  obtains 
consensus  on  a  final  recommendation  within 
10  workdays  after  completion  of  the 
technical  and  functional  reviews. 

•  If  the  technical  and  functional  review 
recommendations  are  not  the  same.  Fleet 
Logistics  DA  will  coordinate  with  the  data 
steward  to  resolve  the  conflict. 

•  If  the  conflict  cannot  be  resolved  by  Fleet 
Logistics  DA,  Fleet  Logistics  DA  will 
forward  the  issue,  together  with  respective 
recommendation,  to  the  Director  of  Coast 
Guard  Engineering  Logistics  for  resolution. 

•  If  the  conflict  cannot  be  resolved  at  that  level 
it  will  be  forwarded  to  Senior  Information 
Resources  Management  for  final  resolution. 

12 

Fleet  Logistics  DA 

Review  of  the  metadata  repository  for  the 
existence  of  any  similar,  usable  data  elements. 

13 

Fleet  Logistics  DA 

Changes  the  status  of  the  data  element  to 
approved  when  the  final  recommendation  is  for 
approval. 

14 

Fleet  Logistics  DA 

•  Changes  the  status  of  the  data  element  to 
disapproved  when  the  final  recommendation 
is  for  disapproval. 

•  Notifies  the  data  steward  and  the  submitter 
of  the  data  element  of  the  disapproval.  After 
notification  of  disapproval,  the  submitter 
may  either  delete  the  data  element  from  the 
repository  or  make  appropriate  changes  and 
resubmit  the  data  element. 
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4.5.  Maintain  Data  Elements 


Purpose  Approved  standard  data  elements  can  be  implemented  or  modified  for  use  in 

various  applications  or  information  systems,  or  they  may  be  archived  when  no 
longer  needed.  Archived  standard  data  elements  may  be  reinstated  for  use. 

The  following  maintenance  procedures  describe  the  processes  for  registering  use 
of  a  data  element  by  an  application,  modifying  approved  data  elements,  archiving 
standard  data  elements,  and  reinstating  archived  standard  data  elements.  For 
more  details  on  the  change  management  and  version  controls  functions  of  data 
administration,  refer  to  Section  7,  Control  Changes  to  Metadata. 


Receive  and  Fleet  logistics  DA  uses  the  following  procedure  to  receive  and  record  requests 
Record  for  changes. 

Requests 


Step 

Action 

1 

Check  and  log  in  submittal  package 

2 

When  all  requested  changes  have  been  approved  or  resolved 
satisfactorily,  integrate  any  approved  changes  into  the  standard  data 
repository.  Procedures  for  making  changes  are  discussed  in  the  topics 
below. 

Registering 
Data  Element 
Applications 


All  new  information  systems  and  migration  information  systems  must  be 
registered  in  the  fleet  logistics  data  repository.  Upon  system  acceptance  of  a  new 
information  system  and/or  application,  those  standard  fleet  logistics  data 
elements  used  by  that  system  and/or  application  are  updated  accordingly. 


Register  applications  of  each  standard  data  element  according  to  the  following 
procedures. 


Continued  on  next  page 
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4.5.  Maintain  Data  Elements,  continued 


Registering  Data  Element  Applications  (continued) 


Step 

Action 

1 

For  new  applications  and/or  information  systems  and  migration  systems 

using  standard  data  elements,  do  the  following: 

a.  Record  the  standard  data  element  name  for  which  the  application  is 
being  registered. 

b.  Record  the  standard  data  element  component  code. 

c.  Record  the  identification  of  the  application  {Automated  information 
software  system  identifier). 

d.  Record  the  name  of  the  application  (Automated  information  software 
system  name). 

e.  ,  Record  the  standard  data  element  access  name. 

2 

The  following  information  is  required  to  assist  in  the  evolutionary 
transition  to  the  use  of  standard  data  elements  for  migration  systems  not 
using  standard  data  elements: 

a.  Review  the  repository  to  identify  the  standard  data  element 
corresponding  to  the  existing  system’s  data  element.  If  no  standard 
data  element  exists,  go  sub-step  b.  If  a  standard  data  element  does 
exist,  do  the  following. 

•  Record  the  application  for  which  the  data  element  is  being 
registered. 

•  Record  the  standard  data  element  component  code. 

•  This  completes  the  process  of  registering  the  data  element. 

b.  Record  the  identification  of  the  application  {Automated  information 
software  system  identifier). 

c.  Record  the  name  of  the  application  {Automated  information  software 
system  name). 

d.  If  there  are  any  variances  between  the  attribute  values  of  the  data 
element  for  which  the  application  is  being  registered  and  the 
attribute  values  of  the  standard  data  element,  follow  the  procedures 
for  a  Modified  data  element  (see  Section  4.2.3,  Data  Element  Life 
Cycle,  item  Stages  of  a  Data  Element’s  Life  Cycle,  for  a 
discussion  on  the  Modified  stage  for  a  data  element).  This  includes 
recording  the  data  element  attributes  that  do  not  correspond  to  the 
standard  data  element. 

Continued  on  next  page 
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4.5.  Maintain  Data  Elements,  Continued 


Registering  Data  Element  Applications  (continued) 


e.  Record  a  standard  data  element  access  name. 

•  Data  element  access  names  provide  the  direct  link  between  the 
standard  data  elements  defined  in  the  repository  and  the 
application  of  those  standard  data  elements  in  automated 
information  systems. 

•  The  length  of  access  names  (i.e.,  identification  of  data  fields  in 
database  and  file  structures)  is  important  to  analysts,  designers, 
and  programmers  who  must  produce  documentation  and  program 

_ code  using  standard  data  elements. _ 


Modify  When  a  system  developer  or  maintainer  or  data  steward  determines  that  a  data 

Existing  element  should  be  modified,  first  review  the  standard  data  elements  in  the 

Standard  Data  repository  to  verify  that  the  change  needs  to  be  made.  Another  standard  data 
Elements  element  may  exist  that  meets  the  purpose.  When  a  change  request  has  been 

determined  to  be  the  best  way  to  meet  the  information  requirement,  follow  the 
applicable  procedure  in  either  Section  43.1,  Develop  Standard  Data  Element, 
or  Section  4.3.2 ,  Develop  Other  Attributes  of  a  Data  Element  The 
conventions,  rules,  guidelines,  and  procedures  that  apply  to  developmental  data 
elements  also  apply  to  proposed  modifications  of  standard  data  elements. 

The  current  version  of  the  standard  data  element  being  modified  will  be  archived 
upon  approval  of  the  modified  standard  data  element.  Refer  to  the  item  below. 
Configuration  Management  of  Metadata,  for  more  details  on  configuration  and 
version  control  as  performed  by  fleet  logistics  repository  CM. 


Archiving  Standard  data  elements  may  be  changed  to  an  archived  status  based  on  the 

Standard  Data  recorded  use  of  the  standard  data  elements.  The  archived  standard  data  elements 
Elements  are  retained  in  the  repository  for  historical  reference  and  possible  reinstatement 

based  on  changing  functional  information  requirements.  Standard  data  elements 
are  changed  to  an  archived  status  through  the  following  procedures. 


Step 

Action 

1 

Fleet  logistics  DA  will  identify  standard  data  elements  that  are  no  longer 
used  or  needed  by  information  systems  based  on  changes  in  functional 
information  requirements  and  notify  the  appropriate  data  steward. 

Continued  on  next  page 
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4.5.  Maintain  Data  Elements,  Continued 


Archiving  Standard  Data  Elements  (continued) 


Step 

Action 

2 

Based  on  the  recommendation  of  fleet  logistics  DA  to  archive  a  standard 
data  element,  the  data  steward  will  assess  the  functional  or  technical 
need  to  retain  the  standard  data  element. 

3 

If  the  data  steward  determines  that  the  standard  data  element  should  not 
be  archived,  the  data  steward  will  notify  fleet  logistics  DA  to  retain  the 
standard  data  element  in  the  repository  in  its  existing  status  rather  than 
archiving  it. 

4 

If  the  data  steward  determines  that  there  is  no  technical  or  functional 
need  to  retain  the  standard  data  element,  the  data  steward  will  notify  fleet 
logistics  DA  to  change  the  status  of  the  standard  data  element  to  an 
archived  standard  data  element.  There  will  be  a  general  announcement 
in  the  repository  when  this  is  to  occur. 

5 

Fleet  logistics  DA  will  notify  the  affected  data  stewards  of  standard  data 
elements  to  be  deleted  from  information  systems  supporting  the 
respective  functional  areas  based  on  the  using  functional  areas,  systems, 
and  applications  registered  in  the  repository. 

When  the  data  stewards  and  fleet  logistics  DA  establish  the  effective 
date  for  deleting  a  data  element  from  an  information  system(s),  the  data 
steward  for  the  data  element  will  notify  other  data  stewards  of  the 
affected  data  element(s)  and  information  systems  and  the  effective  date 
for  deletion. 

6 

Fleet  logistics  DA  will  delete  the  affected  information  system(s)  from  the 
list  of  users  registered  in  the  repository  on  the  effective  date  for  deletion. 

7 

If  no  information  systems  remain  on  the  list  of  users  registered  in  the 
repository  for  a  standard  data  element,  fleet  logistics  DA  will  notify  the 
appropriate  data  steward  and  recommend  that  the  standard  data  element 
be  archived. 

Reinstating 
Archived 
Standard  Data 
Elements 


A  review  of  the  repository  during  the  data  element  developmental  or 
modification  process  may  locate  an  archived  standard  data  element  that  is 
suitable  for  use.  In  such  a  case,  the  archived  standard  data  element  should  be 
reinstated.  Archived  standard  data  elements  may  be  reinstated  for  use  through 
the  following  steps. 


Continued  on  next  page 
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4.5.  Maintain  Data  Elements,  Continued 


Reinstating  Archived  Standard  Data  Elements  (continued) 


Step 

Action 

1 

Notify  the  appropriate  data  steward  that  an  archived  standard  data 
element  exists  and  recommend  that  the  archived  standard  data  element  be 
reinstated  as  a  standard  data  element. 

2 

The  data  steward  will  review  the  archived  standard  data  element  for 
applicability  and  accuracy. 

3 

If  the  archived  standard  data  element  is  accepted  by  the  data  steward,  the 
data  steward  will  notify  fleet  logistics  DA  that  the  archived  standard  data 
element  is  to  be  reinstated  and  the  effective  date  for  reinstatement. 

4 

Based  on  the  approval  and  notification  by  the  data  steward,  fleet  logistics 
DA  will  change  the  status  of  the  archived  standard  data  element  to  an 
approved  standard  data  element. 

5 

After  the  archived  standard  data  element  has  been  reinstated  as  an 
approved  standard  data  element,  the  application  using  the  reinstated 
standard  data  element  must  be  registered  in  the  repository. 

Configuration  Fleet  logistics  DA  ensures  that  any  changes  requested  are  in  relation  to  the 

Management  current  version  of  a  data  element  in  the  fleet  logistics  data  repository.  This 

of  Metadata  assures  system  developers,  system  maintainers,  and  users  that  any  data  element 
they  are  referencing  is  current  and  approved.  Any  changes  to  data  elements  will 
update  systems  and  applications  which  use  that  data  element,  as  controlled  and 
maintained  by  fleet  logistics  repository  administrator.  Refer  to  section  3.4, 
Receive  and  Evaluate  Data  Model,  for  a  discussion  of  this  step. 


CASE  Changes  that  have  been  approved  by  the  DA  are  recorded  in  the  fleet  logistics 

Repository  data  repository.  Details  about  the  fleet  logistics  data  repository  are  discussed  in 

Section  3.1.6,  Maintain  Configuration  of  Data  Models,  subsection  CASE 
Repository. 


Install  and  Use  this  process  to  propagate  metadata  changes  to  relevant  users  and  to  other 
Release  concerned  parties: 

Metadata 

Changes 


Continued  on  next  page 
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Install  and  Release  Metadata  Changes  (continued) 


Step 

Action 

1 

Log  in  the  new  changes  and  assign  version  numbers. 

2 

Apply  changes  to  the  model  as  needed  and  determine  the  impact  on 
applications. 

3 

Notify  those  systems  applications  which  make  use  of  the  metadata 
change. 

Standardize  Data  Elements 


4.6.  Improve  the  Data  Element  Definition  Process 


Purpose  As  part  of  the  review  and  negotiation  cycles  that  are  described  above,  issues  will 

be  raised  and  refinements  will  be  negotiated  that  will  improve  the  data  element 
approval  process.  These  improvements  must  be  documented  and  incorporated 
into  the  data  administration  system.  The  following  procedures  show  how  to 
document  and  submit  the  typical  kinds  of  decisions,  refinements,  and  lessons- 
leamed  as  they  become  apparent. 


Responsi-  The  individuals  who  are  working  with  development  teams  to  standardize  the 
bility  elements  are  in  the  best  position  to  recommend  improvements  to  this  process. 

The  standards  and  the  process  must  improve  continuously  if  it  is  to  meet  the 
changing  needs  of  the  fleet  logistics  community.  Attention  to  this  duty  is  as 
important  as  any  other  standardization  task. 


Identify  Metadata  quality  issues  include  conditions  that  harm  the  validity  of  a  data 

Metadata  standard,  defeat  security  principles,  and  cause  data  to  be  useless  or  deficient 

Quality  Issues  across  the  data  model. 

The  following  procedures  describe  the  general  actions  to  address  metadata 
quality  issues. 


Step 

Action 

1 

Record  and  analyze  those  instances  when  metadata  quality  issues  occur. 

2 

Identify  the  recurrent  problems  and  determine  the  causes. 

3 

Prepare  metadata  changes  according  to  normal  procedures  (see  Section 
4.5,  Procedures  to  Maintain  Data  Elements). 

4 

Submit  metadata  changes  according  to  normal  procedures  (see  Section 
4.5,  Procedures  to  Maintain  Data  Elements). 

Continued  on  next  page 
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4.6.  Improve  the  Data  Element  Definition  Process,  Continued 


Identify 
Requirements 
for  Data 
Element 
Standardization 


New  research  on  data  modeling  principles  may  show  the  current  design  of  the 
data  elements  to  be  deficient.  Refinements  in  the  design  of  data  elements 
improve  the  clarity  of  the  data  will  help  system  developers  and/or  system 
maintainers  define  and  propose  more  useful  data  elements. 

The  following  procedures  describe  the  general  actions  to  address  deficiencies  in 
the  data  element  standardization  process. 


Step 

Action 

1 

Record  and  analyze  the  errors  system  designers  make  when  proposing 
new  data  elements. 

2 

Identify  the  recurrent  problems  and  determine  the  causes. 

3 

Review  any  "lessons  learned"  documentation  from  previous  system 
design  efforts  and  determine  if  any  of  these  lessons  apply  to  the 
identified  problems. 

4 

Review  the  current  academic  research  on  data  modeling  and  determine  if 
any  of  the  new  thinking  on  data  modeling  applies  to  the  identified 
problems. 

5 

Restructure  the  data  model,  if  necessary,  using  the  standard  updating  and 
Configuration  Management  procedures  outlined  in  Section  7,  Control 
Changes  to  Metadata. 
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SECTION  5 

SHARE  DATA  BY  MAPPING  AND  MIGRATION 
5.1.  Overview 


Introduction  This  section  addresses  how  and  when  to  map  metadata  from  an  existing,  isolated 
(legacy)  information  system  to  standard  metadata.  Using  standard  metadata  as 
the  common  reference  saves  time  because  the  mapped  data  can  then  be  shared 
with  any  standard  fleet  logistics  information  system.  The  DA  program  focuses 
on  moving  information  resources  from  the  current  (multiple  isolated  systems) 
data  environment  to  the  future  (enterprise-wide  standard)  data  environment.  This 
section  addresses  the  near-term  problem  of  sharing  data  between  legacy  and 
standard  systems,  and  of  migrating  data  values  from  a  legacy  system  to  a 
standard  information  system. 


In  this  Section  This  section  contains  the  following  topics: 


Topic 

Section 

Overview 

5.1 

Map  Data 

5.2 

Migrate  Data 

5.3 

Establish  and  Maintain  the  Legacy  Data  Element  Inventory 

5.4 

Data  Mapping  This  section  covers  two  similar  but  distinct  ways  to  share  data: 

VS.  Migration  •  Data  Mapping:  Matching  a  data  field  in  a  legacy  system  (definition  and 
attributes)  to  a  standard  data  element  name,  definition,  and  attributes.  The 
"map"  is  the  document  that  shows  the  translation  between  legacy  system 
fields  and  standard  data  elements. 

•  Data  Migration:  Matching  a  data  field  in  a  legacy  system  (definition  and 
attributes)  to  a  standard  data  element  name,  definition,  and  attributes.  The 
"map"  is  the  document  that  shows  the  translation  between  legacy  system 
fields  and  standard  data  elements. 

So,  use  data  mapping  when  the  data  is  to  remain  in  a  legacy  system,  but  some 
fields  must  be  shared  with  other  systems  through  redefinition  or  use  of  an 
interface  or  broker  system.  Use  data  migration  to  move  legacy  data  values  to  a 
standard  system. 


Continued  on  next  page 


Share  Data  by  Mapping  and  Migration 

5.1.  Overview,  Continued 


Ad-Hoc  Data  Do  not  map  data  from  one  legacy  system  directly  to  another  legacy  system, 
Mapping  without  reference  to  the  enterprise  data  model.  Such  ad-hoc  mapping  is 

counterproductive  because  it  will  have  to  be  done  again  when  the  legacy 
system(s)  is(are)  standardized.  Mapping  with  reference  to  the  enterprise  data 
model  starts  the  process  toward  standardization  and  identifies  significant 
problems  in  data  definition. 


Logical  to  The  recommended  style  of  mapping  is  a  logical-to-physical  linkage  of  the  data 
Physical  elements.  This  type  of  map  links  the  legacy  (physical)  data  element  to  the 

Mapping  appropriate  standard  data  element  in  the  fleet  logistics  logical  data  model.  The 

attribute  name  from  the  fleet  logistics  logical  data  model  is  given  to  the 
appropriate  legacy  data  element.  Logical-to-physical  mapping  is  applied  to 
legacy  data  elements  that  must  be  standardized  (for  sharing,  reference, 
compatibility  with  imported  data  or  other  requirement).  In  most  cases,  the  legacy 
data  values  must  then  be  checked  and  edited  (“cleansed”)  for  conformance  to  the 
standard  data  element’s  domain,  definition,  and  attributes. 


Sharing 
Standard  Data 


Central  to  the  objectives  of  the  target  fleet  logistics  data  environment  as 
described  in  Section  2.3  are  the  reuse  and  sharing  of  fleet  logistics  data.  The 
following  table  links  the  goals,  objectives,  and  DA  operations  that  support  data 


conversion. 


Goal 

Objective 

Operational  Service 

Provide  the  means  for  a 
fleet  logistics  shared  data 
resource  (Goal  1) 

Provide  for  data 
interchange  between 
systems  and  among 
organizations 

•  Manage  Data 

Models 

•  Standardize  Data 
Elements 

•  Data  Mapping 

Improve  accessibility  and 
ease  of  use  of  the  data 
resource.  (Goal  3) 

Facilitate  data 
accessibility  across 
locations,  applications, 
and  platforms  by 
providing  standards  and 
mechanisms. 

•  Manage  Data 

Models 

•  Standardize  Data 
Elements 

•  Data  Mapping 

Legacy  data  element  mapping  is  a  higher-level  operation  to  migrate  data  from  a 
current  (legacy)  data  environment  to  the  target  (standard,  shared)  data 
environment.  Data  migration  is  accomplished  through  an  iterative 
standardization  process  that  reconciles  the  legacy  data  with  standard  metadata, 
then  physically  moves  the  data  values  to  the  standard  system. 


Continued  on  next  page 
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5.1.  Overview,  Continued 


Share  Data  by  Mapping  and  Migration 


Responsi¬ 

bility 


To  map  data  for  sharing  or  to  migrate  data  to  a  standard  system,  participation  by 
all  components  of  the  developer  and  mission  area  communities  is  critical.  The 
following  components  have  specific  responsibilities: 

•  System  Development  and  Maintenance:  Obtain  the  current  enterprise  data 
model  and  data  element  definitions.  Define  the  legacy  data  items  in  terms  of 
standard  data  element  definitions.  Prepare  requests  for  new  or  modified  data 
elements  when  no  matching  standard  data  element  definition  can  be  found  or 
adapted.  Write  and  submit  a  Data  Conversion  Plan  and  other  data-related 
deliverable  documents,  and  revise  if  necessary.  The  system  analysis, 
interface  development,  database  design,  and  transition/integration  teams  must 
participate  in  this  effort. 

•  Data  Administration:  Ensure  that  each  system  upgrade  procurement 
Statement  of  Work  includes  a  data  conversion  plan  for  legacy  data,  and  labor 
categories  for  data  administration.  Ensure  that  all  legacy  data  elements  are 
mapped  to  standard  data  elements,  and  that  all  legacy  data  values  that  should 
be  migrated  to  the  successor  system  are  successfully  moved.  Provide  rapid 
response  time  and  sufficient  support  to  facilitate  timely  system  upgrade  or 
data  conversion.  Provide  helpful  reviews  of  submitted  metadata  and  design 
documents.  Provide  clear  and  consistent  dispositions  of  requests.  Update 
and  distribute  standards  information  in  a  timely  manner.  Participate  in 
review  of  metadata-related  deliverables  and  in  system  acceptance  testing. 

•  Data  Stewardship:  Remain  familiar  with  the  data  in  nonstandard  systems 
that  utilize  the  steward’s  assigned  information  classes.  Anticipate  data 
standardization  and  conversion  problems.  Review  candidate  data  element 
requests  and  standard  data  element  modification  requests  in  a  timely  but 
through  manner.  Ensure  that  each  project’s  “data  cleansing  strategy”  for 
preparing  data  values  effectively  prepares  legacy  data  to  be  shared  with  the 
enterprise.  Act  as  an  advocate  for  the  users  of  the  assigned  categories  of 
information. 

•  Program  Management:  Ensure  that  data  element  mapping  is  accomplished 
and  approved  before  permitting  physical  database  design  or  software  coding 
to  start.  Ensure  the  participation  of  DA  representatives  in  review  of 
metadata-related  deliverables  and  in  acceptance  testing.  Ensure  that 
conversion  of  legacy  data  (successful  migration)  and/or  construction  of  a 
reliable  broker/interface  (effective  mapping)  constitutes  a  key  segment  of  the 
system  acceptance  test.  Ensure  that  the  appropriate  data  quality  checks  are 
performed. 
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5.2.  Map 


Introduction 


The  Mapping 
Process 


Objective 


Data 


This  subsection  shows  how  and  when  to  map  shareable  data  that  resides  in  a 
legacy  system.  Use  this  process  when  the  data  will  remain  in  the  legacy  system, 
but  must  be  shared  with  other  CG  systems.  Also  use  this  process  to  map  standard 
data  that  will  be  used  by  a  legacy  system. 

The  resulting  map  can  be  used  to: 

•  Rename  and  reformat  data  fields  in  the  legacy  system  to  standard  data 
element  names  and  formats 

•  Create  a  conversion  table  that  matches  legacy  system  fields  to  standard  data 
elements 

•  Build  a  broker  system  or  interface  module  that  translates  the  legacy  system 
fields  to  standard  data  elements,  alters  the  format  of  inbound  or  outbound 
data  values  accordingly,  and  filters  data  values  for  conformance  to  standard 
domain  and  attributes. 


Data  mapping  is  the  process  of  associating  data  elements  in  legacy  systems  with 
the  designated  migration  systems  or  migrating  near-term  initiatives.  The  legacy 
data  element  map  is  a  bridge  connecting  legacy  data  elements  to  functional 
processes  and  associated  data  models.  Mapping  may  require  modification  of  the 
legacy  system's  data  definitions,  data  structures,  or  application  software  to 
support  the  standard  data  element  definition. 

Legacy  data  element  mapping  is  necessary  to  ensure  that  all  materials, 
equipment,  and  facilities  represented  by  the  legacy  data  elements  are  linked  to 
their  replacement  system.  Data  mapping  is  also  necessary  to  position  legacy  data 
elements  for  standardization  by  linking  existing  data  elements  to  the  standard 
logical  data  model.  It  is  useful  for  accurately  assessing  the  data  impact  and  scope 
of  near-term  initiatives,  migration  systems,  and  functional  process  improvements. 


Legacy  data  element  mapping  addresses: 

1 .  Legacy  data  elements  mapped  to  migrating  data  elements  to  facilitate  data 
conversion  and/or  data  exchange  between  the  information  systems.  This 
preserves  investment  in  the  data  resource  and  ensures  logistics  operational 
effectiveness  during  system  and  data  migrations. 

2.  Legacy  data  elements  mapped  to  new  approved  functional  data  models. 
This  positions  legacy  data  elements,  which  are  non-standard  data  elements, 
for  future  standardization. 


Continued  on  next  page 
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Share  Data  by  Mapping  and  Migration 


When  to  Map 


Mapping 

Functions 


An  isolated  information  system  can  serve  its  users  adequately  without  mapping, 
upgrading,  or  standardizing,  as  long  as  system  requirements  remain  unchanged. 
Previous-generation  systems  were  designed  to  operate  self-sufficiently,  without 
taking  data  from  or  contributing  data  to  a  shared  information  resource.  Current 
CG  information  resource  management  policy,  mandates  for  efficient  operation, 
and  business  process  improvement  all  point  toward  sharing  of  information 
resources.  Therefore,  mapping  (rather  than  migration  to  a  standard  system)  can 
serve  as  a  temporary  measure  to  support  data  sharing  when  the  following 
conditions  are  true: 

•  The  requirement  for  data  sharing  is  occasional 

•  The  data  values  are  shared  in  batch  mode,  and  can  be  filtered  or  checked 
before  use 

•  The  shared  data  is  to  be  used  as  reference/lookup  files  only 

•  This  data  sharing  requirement  is  a  test  of  whether  the  data  in  question  should 
be  shared 

•  The  mapping  is  relatively  straightforward,  and  will  not  require  extensive 
changes  to  the  legacy  system's  application  software 

•  The  mapping  will  not  introduce  inconsistency  between  files,  value  errors,  or 
data  integrity  problems 

•  More  extensive  analysis  is  not  appropriate  because  a  replacement  standard 
system  is  in  planning  or  development. 

In  addition  to  required  standardization,  starting  the  mapping  process  early  will 
avoid  errors  that  might  develop  under  deadline  pressure.  Each  current  fleet 
logistics  information  system  is  encouraged  to  initiate  the  process  of  mapping  its 
current  data  structures  and  data  element  definitions  to  enterprise  standard 
metadata. 


For  each  field  in  the  legacy  system’s  database,  list  the  legacy  field's  name, 
attributes,  domain  of  values,  and  business/validation  rules,  and  the  file  or  table 
where  it  resides.  For  those  fields  that  correspond  to  a  standard  data  element, 
indicate  the  standard  data  element  name.  The  remaining  fields  may  require 
closer  analysis  to  determine  whether  the  field  can  be  adapted  to  match  a  standard 
data  element,  if  the  standard  data  element  attributes  or  definition  should  be 
modified,  or  if  a  new  data  element  should  be  proposed. 

Mapping  requires  modification  of  the  legacy  system’s  data  structure  (and 
updating  the  application  software),  or  creating  an  interface  module  that  converts 
and  checks  inbound  and  outbound  data  values. 

A  worksheet  for  preliminary  analysis  and  tracking  of  all  legacy  data  items  is 
provided  in  Appendix  D. 
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5.2.  Map  Data,  Continued 


Key 

Responsi¬ 

bilities 


The  key  responsibilities  involved  in  data  mapping  are: 

1 .  Establishing  and  maintaining  a  legacy  data  element  inventory. 

2.  Resolving  conflicting  legacy  data  element  names  and  definitions. 

3.  Identifying  redundant  legacy  data  elements. 

4.  Associating  mapping  data  elements  with  data  elements. 

5.  Associating  legacy  data  elements  with  candidate  standard  data  elements. 

6.  Implement  approved  map  in  the  legacy  system,  by  modifying  the  software 
and  data  structures  or  creating  an  interface  module. 

7.  Edit  and  check  (“cleanse”)  data  values  for  attributes,  domain,  business 
rules,  etc.,  so  that  data  values  will  be  shared  reliably  as  intended. 


When  Not  to 
Map 


Do  not  map  legacy  data  elements  used  for  controlling  internal  system  processing. 
This  data,  usually  consisting  of  scratchpads,  internal  counters,  and  system 
performance  indicators,  is  of  no  interest  to  fleet  logistics  users  on  other  systems 
and  so  it  need  not  be  shared.  Standards  for  internal  data  may,  however,  be  useful 
for  other  purposes  such  as  reusable  software. 

To  standardize  an  application  system  in  accordance  with  the  fleet  logistics 
enterprise  data  model,  refer  to  Section  3,  Develop  and  Integrate  Data  Models, 
and  Section  4,  Standardize  Data  Elements. 


A  system  that,  due  to  the  level  of  changes  or  requirement  for  data  sharing,  must 
be  redesigned  using  the  enterprise  data  model  is  not  a  candidate  for  mapping. 
The  system's  logical  and  physical  data  model  must  be  designed  from  the 
enterprise  standard  data  model  when  any  of  the  following  are  true: 

•  Substantial  upgrade  of  the  software,  equipment,  or  communications 

•  Significant  changes  in  the  users'  business  processes 

•  Changes  in  legal  or  regulatory  requirements  affecting  the  system's  data 

•  Requirement  to  share  data  routinely  with  other  CG  information  systems 
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Data  Mapping 
Process 


The  following  table  shows  how  to  identify  data  mapping  requirements, 
accomplish  the  mapping,  and  start  to  share  standard  data. 


How  to  Map  a  Legacy  System  to  Standard  DEs 


Step 

Action 

Process 

1 

Identify  Requirement 

Identify  in  the  source  and  destination  system(s)  the 
data  fields  that  must  be  shared,  and  the  additional 
data  fields  that  are  affected  (changed,  used, 
combined)  by  the  selected  data  items  in  their 
respective  systems.  A  worksheet  for  identifying 
shared  data  is  provided  in  Appendix  D. 

2 

Assess  Legacy 
System 

Obtain  and  review  the  legacy  system's  Database 
Design  Document  and  the  analytical  work  that  led 
to  the  system's  logical  and  physical  design. 

Review  the  system's  data  model  to  verify  the 
implications  of  changing  the  selected  data  items. 
Determine  the  other  changes  required  to  support 
changes  in  the  attributes  of  the  selected  data  items. 

3 

Analysis 

Obtain  and  review  the  current  enterprise  data 
dictionary.  Identify  the  standard  entities  and  data 
elements  that  appear  to  match  the  selected  data 
items  in  the  legacy  system.  Also  identify  the 
selected  data  fields  for  which  no  match  can  be 
found  in  the  enterprise  data  dictionary. 

4 

Map  Standard  Data 
Elements 

For  fields  that  can  be  described  by  a  standard  data 
element,  note  the  adjustments  to  be  made  in  the 
legacy  system  (application  software,  data  tables,  or 
interface  module). 

5 

Request  New  Std. 
Data  Elements 

For  fields  for  which  no  match  can  be  found,  create 
a  Request  for  Data  Element  Definition,  as 
described  in  Section  4.  This  definition  may 
require  adjustment  after  DA  review. 

6 

Map  New  Std.  Data 
Elements 

Using  the  approved  version  of  the  data  element 
definition,  map  the  newly  approved  data  element 
to  the  appropriate  field.  Indicate  necessary 
modifications. 

Continued  on  next  page 
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5.2.  Map  Data,  continued 


Data  Mapping  Process  (continued) 


7 

Submit  Plan 

Submit  to  fleet  logistics  DA  a  Data  Conversion 

Plan.  The  plan  must: 

1 .  Identify  all  data  to  be  shared,  by  standard  and 
proposed  data  element  names  and  attributes 

2.  Show  how  the  shared  data  will  be  generated  or 
used  in  the  legacy  system 

3.  If  data  will  be  processed  by  an  interface  or 
broker  module,  describe  the  processing 
method  and  demonstrate  conformance  to 
standard  metadata 

4.  Show  how  the  data  values  will  be  cleansed  and 
validated  for  sharing,  and  how  the  mapping 
strategy  will  be  validated  and  tested. 

8 

Modify  Software 

After  approval  of  the  Data  Conversion  Plan, 
modify  the  application  software  to  accommodate 
and  support  the  mapped  fields.  Preferably, 
modifications  will  be  to  the  application  software. 

If  necessary,  modifications  can  be  applied  to  an 
interface  module  that  brokers  data  between  the 
application  system  and  other  systems. 

9 

Test  &  Adjust 

Test  the  validity  of  the  mapping  by  using,  for  each 
data  item,  test  data  that  represents  the  full  extent  of 
the  domain  of  the  standard  data  element. 

10 

Validate  &  Register 

Fleet  logistics  DA  will  review  the  test  results  and 
register  the  mapped  system  for  sharing  values  for 
the  specified  standard  data  elements. 

11 

Share  Standard  Data 

Use  the  standard  process  for  bringing  a  new 
system  online. 

T riggering  The  data  mapping  process  is  initiated  by  the  need  to  identify,  describe,  match. 

Event  document  data  elements  in  legacy  information  systems  which  must  share 

data  with  other  (standard  or  legacy)  fleet  logistics  information  systems. 


Principal  The  documents  resulting  from  the  mapping  exercise  are: 

ReSU  Its  1  •  Legacy  data  element  inventory  (refer  to  Section  5.4). 

2.  Legacy  data  element  to  standard  data  entity  map. 

Save  these  documents  for  use  when  the  legacy  system  is  upgraded  to  a  standard 
system. 


Continued  on  next  page 
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Share  Data  by  Mapping  and  Migration 


Implementa¬ 
tion  Roles 


1 .  Fleet  logistics  DA  is  the  steward  of  the  legacy  data  element  inventory  and 
owner  of  the  approved  data  element  map.  The  inventory  and  map  will  be 
placed  under  configuration  management. 

2.  The  users  of  the  legacy  system  “own”  the  legacy  data  elements.  As  soon  as 
possible,  the  legacy  data  elements  should  be  converted  to  standard  data 
elements  and  responsibility  turned  over  to  the  data  steward  for  the 
appropriate  information  class. 

3.  The  roles  involved  in  the  legacy  data  element  mapping  process  are: 

•  Fleet  logistics  data  administration 

•  Data  stewards  and  subject  matter  experts  for  the  appropriate  information 
classes 

•  Functional  project  manager 

•  Technical  developer. 
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5.3.  Migrate  Data 


Introduction  This  subsection  shows  how  to  move  data  from  a  legacy  system  to  a  standard 
system,  making  the  changes  to  ensure  the  data  is  usable  by  standard  systems. 


As  part  of  the  plan  for  upgrading  an  existing  system  (Milestone  1),  the  user 

organization  and/or  developer  shall  submit  a  Data  Conversion  Plan.  Additional 

information  regarding  the  Data  Conversion  Plan  is  provided  in  Sections  8  and  11. 

The  Data  Conversion  Plan  shall  include  the  following  information: 

•  Description  of  the  current  data  structure  and  data  entity  definitions 

•  Identification  of  standard  data  entities  that  will  meet  the  equivalent  functional 
need 

•  Identification  of  current  data  entities  for  which  no  satisfactory  standard  entity 
has  been  found,  and  the  recommended  disposition  (new  entity,  expand  definition 
of  a  standard  entity,  or  request  waiver  for  the  entity). 

•  Indication  of  update  cycle  for  each  entity  that  requires  synchronization 

•  Indication  of  data  ownership  and  access  criteria  for  each  classified  entity  and  for 
data  that  requires  restricted  access. 

•  Definition  of  validation  formulas  for  critical  data  that  requires  systematic 
validation. 

•  Identification  of  data  from  the  standard  resource  that  could  be  used  in  this 
application 

•  Identification  of  data  from  this  application  that  could  be  contributed  to  the 
standard  resource. 

•  Strategy  for  editing  and  checking  (cleansing)  the  data  values  for  data  sharing. 

•  Proposed  new  data  structure 

•  Proposed  migration  path  from  current  data  structure  (and  external  data 
interfaces)  to  the  new  standard  data  structure  (and  external  data  interfaces). 

After  authorization  of  the  system  upgrade,  the  Data  Conversion  Plan  will  become 

the  preliminary  Database  Description  Document  (DBDD). 


Data 

Conversion 

Plan 


Data 

Migration 

Process 


Figure  5-1  shows  a  simplified  data  migration  process.  The  simplification  is 
useful  for  describing  its  principal  steps.  The  process  begins  by  mapping  the  data 
elements  of  the  legacy  system(s)  to  the  data  elements  of  the  migration  system  or 
near-term  initiative.  The  map  in  the  Data  Conversion  Plan  facilitates  the  cleanup 
of  the  legacy  data  elements  and  identifies  redundant  and  ambiguous  data  items. 
Then  the  developer  cleanses  the  data  values  to  meet  the  standard  data  element 
definitions.  The  final  step  is  to  move  the  data  values  from  the  legacy  system  to 
the  standard  system. 


Continued  on  next  page 
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5.3.  Migrate  Data,  Continued 


Data  Migration  Process 

Legacy  Data  Data  Map  Standard  Data, 

Consistent  With 


Figure  5-1.  Data  Migration  Process 


Triggering 

Event 


The  data  migration  process  is  initiated  by  the  need  to  identify,  describe,  match, 
and  document  data  elements  in  legacy  information  systems  which  are  being 
replaced  by  standard  information  systems.  The  focal  point  of  this  process  is  the 
developer’s  Data  Conversion  Plan,  and  the  supporting  data  element  requests  (if 
any). 


Data 

Migration 

Approval 


The  list  of  data  elements  to  be  migrated  will  be  submitted  and  approved  as  a  Data 
Conversion  Plan.  For  data  elements  the  developer  identifies  as  new  or  requiring 
revision,  the  developer  or  maintainer  will  submit  a  data  element  request,  as 
described  in  Section  4.  The  developer  or  maintainer  submits  candidate  standard 
data  elements  to  fleet  logistics  DA,  for  the  data  element's  technical  approval  and 
for  integration  into  the  enterprise  data  model.  The  data  steward  for  the 
appropriate  information  class  reviews  the  request  as  described  in  Section  8. 

Once  the  DA  determines  that  the  data  element  satisfies  all  technical  and 
functional  criteria,  it  is  approved  as  a  standard  data  element. 

This  process  may  iterate  several  times  for  migration  data.  During  this  process  the 
data  is  separated  from  the  particular  application.  When  the  process  is  completed, 
the  data  elements  are  standardized  and  independent.  They  are  maintained  as  a 
part  of  the  logistics  enterprise  data  environment. 
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5.4.  Establish  and  Maintain  the  Legacy  Data  Element 
Inventory 


Introduction  Data  element  mapping  and  data  migration  both  require  development  of  an 

inventory  of  legacy  data  elements  (data  fields  in  a  physical  database,  along  with 
their  definitions  and  attributes).  When  data  in  a  legacy  system  is  to  be  shared, 
this  inventory  is  the  basis  for  identifying  which  data  items  (values  in  physical 
fields)  will  be  shared  (and  therefore  mapped  to  standard  DEs).  When  data  is  to 
be  migrated,  the  inventory  is  the  basis  for  determining  how  data  values  are  to  be 
modified  to  conform  to  standard  data  element  definitions. 

In  addition,  the  collection  of  inventories  from  various  legacy  information  systems 
document  how 


Inventory 
the  Legacy 
Data 

Elements 


Once  the  decision  is  made  to  map  legacy  data  elements,  the  first  step  is  to  create 
an  inventory  of  legacy  data  elements  for  those  systems  being  replaced.  The 
inventory  is  an  identification  of  the  data  element,  its  associated  data  model  (if 
one  exists),  and  other  information  about  the  data  element.  This  may  require  the 
collection  of  system  documentation,  file  layouts,  record  layouts,  procedures,  job 
control  steps,  physical  database  descriptions,  or  copybooks.  Document  the 
business  rules  that  are  represented  in  the  user  procedures  and  software  processes. 


The  data  element  mapping  team  should  prepare  the  data  element  inventory  for 
the  DA  repository. 


Develop  the 
Inventory 


The  developer  or  maintainer  will  develop  the  legacy  data  element  inventory, 
using  the  listing  of  the  application’s  data  structure  (files  or  tables,  fields  or 
columns,  and  attributes)  as  a  starting  point.  Add  to  each  data  item  the  business 
rules  (from  user  procedures  and  software  algorithms)  for  creating,  updating,  and 
deleting  that  item,  and  any  access  restrictions  for  reading  the  item.  If  requested, 
DA  will  provide  guidance  for  completing  the  inventory. 


When  completed,  the  developer  or  maintainer  will  transmit  the  inventory  to  fleet 
logistics  DA.  The  DA  will  review  the  inventory,  and  may  request  additional 
information  or  modification  before  accepting  it. 


After  the  inventory  is  accepted,  DA  is  responsible  for  maintaining  it.  The  initial 
inventory  is  a  legacy  data  element  baseline,  which  DA  will  place  under 
configuration  control.  Modifications  after  acceptance  will  be  submitted  item-by¬ 
item,  using  the  process  for  a  standard  metadata  change  request. 


Continued  on  next  page 
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5.4.  Establish  and  Maintain  the  Legacy  Data  Element 
Inventory,  continued 


When  to  The  process  of  assessing  and  evaluating  the  legacy  data  elements  begins  after  the 

Start  inventory  has  been  established.  The  assessment  begins  by  determining  which 

legacy  data  elements  will  be  mapped.  This  determination  is  made  according  to 
the  priorities  of  the  functional  project  manager  and  fleet  logistics  DA. 


Establish  If  the  data  element  name  and  description  (in  the  legacy  system)  is  abbreviated  or 
Namo  unclear,  the  technical  developers  and  the  functional  project  managers  have  to 

resolve  this  ambiguity.  This  may  require  giving  the  data  element  a  long,  business 
oriented  name  and/or  definition. 


I 


Resolve 

Ambiguities 


Systems  that  were  designed  by  different  teams  at  different  times  for  different 
purposes  often  have  fundamentally  different  views  of  the  data.  These  design 
assumptions  often  cause  problems  in  data  mapping  and  migration.  One  of  the  most 
difficult  and  critical  tasks  in  mapping  or  migrating  data  is  resolving  these 
differences.  These  discrepancies  must  be  resolved  before  legacy  data  can  be 
mapped  to  standard  metadata.  This  process  may  be  helpful  in  resolving  differences 
in  names  and  definitions; 


Step 

Who 

Action 

1 

Developer  or 
Maintainer 

Compare  the  data  elements  to  identify 
conflicts.  Data  element  conflicts  take  the 
following  form: 

•  Same  name  and  definition  (redundancy). 

•  Same  name,  different  definition 
(homonyms). 

•  Same  definition,  different  name 
(synonyms;  potential  redundancy). 

•  Same  name  and  definition,  different  entity 
association  (synonyms;  potential  redundancy). 

2 

Developer  or 
Maintainer,  with 

DA 

Resolve  conflicts  identified  in  Step  1 .  Given  the 
complexity  of  resolving  a  large  volume  of  data 
element  conflicts,  an  automated  tool  to  support 
this  process  is  highly  desirable. 

3 

Developer  or 
Maintainer 

Document  the  decision  process  for  future 
reference. 

4 

Developer  or 
Maintainer,  with 

DA 

Test  the  decision  on  a  large  sample  of  actual  data 
values  from  the  legacy  system.  Are  the  results 
compatible  with  the  standard  DE  definition  and 
attributes? 

5 

Developer  or 
Maintainer 

Incorporate  the  validated  decision  into  the  Data 
Conversion  Plan. 
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SECTION  6 

MAINTAIN  METADATA  REPOSITORY 


6.1.  Overview 

Introduction  This  section  identifies  functions  that  the  repository  tool  users  perform  on  the  CG 
fleet  logistics  metadata  repository.  This  repository  is  the  central  link  for  all  data 
administration  services.  It  is  the  key  to  re-use  of  logical  data  models,  physical 
data  structures,  and  application  software  modules.  The  specific  set  of  operations 
is  dependent  upon  the  particular  repository  tool.  The  fleet  logistics  repository 
tool  has  not  yet  been  selected.* 

The  metadata  repository  is  not  just  a  data  model  receptacle,  but  a  management 
system  that  supports  development  of  additional  data  models,  integrates  data 
models  from  a  variety  of  applications  and  CASE  tools,  and  permits  convenient 
management  of  all  levels  of  metadata.  A  versatile  repository  provides  a  means 
for  achieving  information  resource  management  and  data  re-use. 

The  following  sections  identify  and  describe  advanced  repository  operations  that 
are  vital  to  providing  DA  operational  services. 


*  NOTE:  At  this  writing  the  platform  and  tools  for  the  fleet  logistics  metadata 
repository  have  not  been  selected.  This  version  describes  the  future  repository's 
requirements  and  functions.  Contact  the  fleet  logistics  DA  for  current 
information. 


In  this  This  section  covers  the  following  topics: 

Section 


Topic 

Section 

Metadata  Repository  Requirements 

6.2 

Operations  on  Data  Models 

6.3 

Operations  on  Data  Elements 

6.4 

Operations  on  Other  Repository  Objects 

6.5 

Repository  Utilities 

6.6 

Continued  on  next  page 
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6.1.  Overview,  Continued 


Metadata  Metadata  means  literally  "data  about  data."  This  term  refers  to  the  means  of 

describing  the  things  one  must  know  about  a  body  of  information  in  order  to 
describe  it  completely  and  systematically.  A  metadata  repository,  then,  is  a  place 
where  metadata  can  be  stored  in  a  systematic  and  useful  form. 

Formal  metadata  includes  categories  of  information  (information  classes), 
subtypes  (logical  entities)  within  those  categories,  and  the  detailed  information 
(atomic  facts  or  data  elements)  contained  in  each  subtype.  It  also  includes  the 
various  relationships  between  the  logical  entities,  including  identification  of 
primary  and  secondary  keys  that  activate  each  relationship.  For  data  elements, 
the  repository  stores  the  standard  name,  aliases,  definition,  attributes,  and 
systems  where  each  is  used. 

This  level  of  precision  in  describing  the  body  of  information  is  critical  for 
creating  a  complete,  valid,  and  application-independent  representation  of  the 
information  in  the  enterprise. 


Repository  A  metadata  repository  manages  the  information  that  describes  the  enterprise's 
data,  such  as  information  classes,  entities,  and  data  elements.  FIPS  PUB  156 
describes  a  repository  as  a  specialized  database  "...  used  to  control,  describe, 
protect,  document,  and  facilitate  use  of  an  installation's  information  resources." 

In  contrast,  a  repository  of  data  values  (a  data  warehouse)  is  a  central  system 
where  information  about  procurements,  national  stock  numbers,  or  vessel  data, 
for  example,  would  be  stored.  The  fleet  logistics  repository  is  a  metadata 
repository,  not  a  data  warehouse.  Values  (instances)  are  stored  in  the  several 
application  systems  that  share  data  according  to  the  fleet  logistics  standard. 

The  fleet  logistics  metadata  repository  function  includes  the  data  administration 
duties  of 

•  Defining  standard  data  entities  and  data  elements 

•  Noting  all  the  instances  where  fleet  logistics  information  systems  use  these 
data  elements 

•  Analyzing  and  validating  the  use  of  data 

•  Controlling  the  versions  of  each  metadata  item 

The  repository  function  also  collects  and  tracks  information  about  all  fleet 
logistics  information  systems  and  data  resources,  including  legacy  systems.  This 
is  the  "wider  repository."  The  wider  repository  includes  business  process/activity 
models,  data  models  and  physical  data  structure  documentation  of  legacy 
systems,  regulations  affecting  data,  and  data  standards  from  other  agencies  and 
supplier  organizations. 


Continued  on  next  page 
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6.1.  Overview,  Continued 


Use  of  the  Fleet  logistics  DA  operates  and  maintains  the  metadata  repository.  The  metadata 
Repository  repository  includes  a  dictionary  that  maintains  information  about  standard  logical 
entities,  data  elements,  relationships,  and  attributes.  Data  administration 
personnel  use  the  repository  for  analysis  and  strategic  data  planning,  to  record 
approved  metadata,  to  register  the  use  of  data  items  in  standard  information 
systems,  to  understand  the  effects  of  proposed  metadata  changes,  and  to  track  the 
status  of  candidate  data  elements.  Data  stewards  contribute  to  and  validate  the 
logical  data  model,  and  use  the  "where-used"  function  to  understand  the  use  of 
specific  metadata.  System  developers  and  maintainers  use  the  repository's 
standard  logical  data  model  as  the  basis  for  designing  application  systems,  and 
mapping  and  migrating  data  from  legacy  systems.  Users  obtain  names  and 
locations  for  data  needed  for  queries  and  reports. 


Scope  of  the 

Fleet 

Logistics 

Metadata 

Repository 


The  fleet  logistics  metadata  repository  maintains  information  about  the  data  in 
the  CG  fleet  logistics  enterprise,  and  information  that  is  supplied  to  or  provided 
by  fleet  logistics  organizations.  The  repository's  logical  data  model  describes  the 
enterprise's  standard  logical  entities  and  standard  data  elements.  In  addition,  the 
"larger"  repository  function  also  collects  metadata  from  fleet  logistics  legacy 
systems  and  attempts  to  reconcile  this  metadata  with  the  standard  metadata. 
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6.2.  Metadata  Repository  Requirements 


Introduction  The  fleet  logistics  metadata  repository  refers  to  both  a  tool  and  a  DA  function. 

DA  provides  administration  and  support  for  the  repository.  The  repository  is  the 
central  broker  of  information  about  the  data  in  standard  fleet  logistics 
information  systems.  The  repository  tool  is  a  database  management  system  that 
maintains  information  about  fleet  logistics  enterprise  data,  and  thereby  supports 
the  metadata  repository  function. 


Categories  of  The  fleet  logistics  metadata  repository  will  provide  the  following  categories  of 
Repository  support  to  the  data  administration  program: 

Requirements  •  Describe  the  enterprise's  data  architecture 

•  Store  and  retrieve  metadata 

•  Provide  multiple  views  of  enterprise  metadata 

•  Integrate  data  models  from  multiple  applications 

•  Support  multiple  CASE  tools 

•  Ensure  consistency  and  completeness  in  standard  metadata 

•  Track  changes  to  metadata 

The  following  paragraphs  describe  these  requirements  at  a  level  intended  for 
evaluation  of  repository  tools  and  understanding  of  the  essential  function  of  a 
metadata  repository. 


Describe  Data  The  fleet  logistics  metadata  repository  implements  and  gives  substance  to  the 
Architecture  fleet  logistics  information  architecture  by  providing  the  following: 

•  Maintain  both  physical  and  logical  views  of  data  and  business  processes. 

•  Enable  the  concurrent  establishment  of  many  different  architectural 
constructs  such  as  data,  application,  organization,  business  process,  and 
technology,  all  being  linked  as  necessary. 

•  Capture  and  represent  the  business  meaning  of  the  data,  and  the  contextual 
relationships  that  transform  data  into  information. 

•  Facilitate  information  exchange  among  internal  and  external  information 
systems,  CASE  tools,  system  development  tools,  and  other  repositories 

•  Support  evolution  of  data  architecture,  scope  of  the  enterprise,  and  CG IRM 
policies 


Continued  on  next  page 
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6.2.  Metadata  Repository  Requirements,  Continued 


store  and 

Retrieve 

Metadata 


The  fleet  logistics  metadata  repository  provides  reliable  storage  of  and  versatile 

access  to  metadata  by  providing  the  following: 

•  Maintain  data  dictionary  information,  design  data  models,  planning  data 
models,  process  models,  data  flow  diagrams,  and  functional  decompositions 

•  Catalog,  analyzes,  correlates,  and  manages  the  enterprise-wide  use  of 
information  resources 

•  Identify  each  information  system  in  which  instances  of  user-specified  data 
elements  are  created,  read,  updated,  or  deleted  (where-used) 

•  View,  update,  delete,  and  retrieves  metaobjects;  allow  users  to  form 
aggregate  repository  objects  that  are  specific  to  a  particular  need 

•  Capture,  store,  and  access  business  rules,  design  decisions,  and  data 
validation  and  synchronization  rules  for  logical  entities  and  data  elements 

•  Capture,  store,  and  access  data  flow  and  system  and  user  access  for  security 
risk  analysis 

•  Capture,  store,  and  access  "planning  objects"  such  as  business  process 
models,  business  goals,  and  organization  missions. 

•  Capture,  store,  and  access  "implementation  objects"  such  as  forms,  user 
procedures,  application  code,  job  control  language  or  scripts,  and  batch  jobs 

•  Capture,  store,  and  access  acquisition  and  development  data  such  as  system 
development  deliverables,  and  the  interrelationship  between  deliverables, 
tasks,  and  requirements 


Provide 

Multiple 

Views 


The  fleet  logistics  metadata  repository  ensures  that  standard  metadata  is  system- 

independent  and  is  useful  to  all  applications  by  providing  the  following: 

•  Provide  shared,  interactive  data  dictionary  services,  with  user-selectable  view 
and  level  of  detail,  through  which  users  can  identify  sources  of  data 
throughout  the  enterprise  and  provide  information  sufficient  for  users  to 
select  desired  items  and  formulate  queries  on  selected  data  values 

•  Permit  joint  analysis  of  requirements  by  specialists  with  different 
backgrounds  and  viewpoints 

•  Identify  sources  of  information  to  support  business  processes 

•  Provide  standard  names,  definitions,  and  terms  for  queries  and  reports 

•  Provides  modeling  and  usage  data  for  planning  and  management  of  the 
information  resource. 

•  Link  logical  data  to  logical  processes  to  identify  instances  (applications) 

•  Identify  standard  data  required  by  processes  and  applications. 

•  Map  logical  (meta)data  to  physical  data  (technology  model) 

•  Provide  correct  foreign  keys 

•  Resolve  and  integrate  various  views  in  a  single  source 

•  Support  impact  analysis  for  proposed  changes  to  standard  metadata 
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Integrate  and 
Manage  Data 
Models 


Support 
Multiple  CASE 
Tools 


The  fleet  logistics  metadata  repository  enables  DA  to  integrate,  reconcile,  and 
manage  data  models  by  providing  the  following: 

•  Document  the  relationships  between  organizations,  locations,  processes,  and 
data  in  the  context  of  operational  business  and  data  requirements 

•  Provide  model  integration  services  for  models,  structures,  items, 
relationships,  and  user  views  at  multiple  levels,  with  requirements 
traceability;  consolidate  attributes  and  resolve  differences  in  item 
specifications. 

•  Provide  model  management  services  including  consolidation  of  attributes  and 
resolution  of  differences  in  item  specifications,  while  maintaining  visibility 
of  the  different  versions  of  model  items  and  tracking  which  version  is  in  use 
by  which  model 

•  Support  evolution  of  the  enterprise  data  model,  and  management  at  all  levels 
of  abstraction  and/or  detail 

•  Coordinate  and  integrate  each  model,  structure,  item,  relationship,  and  user 
view,  at  the  user-specified  level  of  granularity,  both  internally  and  with 
adjacent  higher  and  lower-level  views,  while  maintaining  identification  of 
each  requirement's  origin 

•  Capture,  store,  and  access  data  mapping  and  conversion  rules  to  migrate  from 
legacy  systems  to  standard  metadata 

Note:  The  metadata  import  and  export  facilities  of  each  CASE  tool  are  different.  They 
all  exchange  the  same  basic  information,  but  there  are  important  differences.  Typically, 
business  rules  (constraints,  triggers,  access  rules,  synchronization,  etc.)  present  problems 
when  translating  between  CASE  tools.  When  downloading  a  view  to  start  an  application 
data  model,  work  with  the  DA  repository  administrator  to  determine  which  additional 
information  must  be  added  to  comment  fields  or  kept  separately.  Planning  for  developing 
and  transferring  this  additional  information  will  save  time  during  data  model  review. 


The  repository  system’s  formats  and  interfaces  should  support  the  use  of  major 
industry-standard  CASE  tools  and  database  management  systems,  thereby 
supporting  the  CG’s  need  to  utilize  current  technology  on  a  competitive  basis. 
The  following  requirements  are  intended  to  maintain  the  vendor-neutral  quality 
of  the  repository: 

•  Export  and  import  in  a  variety  of  popular  CASE  tool  formats,  attributed  data 
models  for  user-specified  views,  and  related  metadata 

•  Support  download  of  complete  metadata  for  (subset)  views,  to  populate  an 
application  data  model,  as  the  starting  point  for  data-related  analysis 


Continued  on  next  page 
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6.2.  Metadata  Repository  Requirements,  continued 


Ensure 

Consistency 

and 

Completeness 


The  fleet  logistics  metadata  repository  ensures  the  consistency,  completeness, 

and  quality  of  metadata  by  providing  the  following: 

•  Define  and  enforce  rules  and  policies  related  to  metadata  (naming  standards, 
integrity  rules,  foreign  keys,  attributes,  etc.) 

•  Provides  in  software  the  rigor  and  cross-checking  necessary  to  achieve  a 
valid  enterprise  data  model  by  enforcing  modeling  rules 

•  Ensures  consistent  methods,  nomenclature,  notation,  and  definitions 

•  Supports  object-oriented,  relational,  and  traditional  data  constructs 

•  Provide  for  online  and  batch  entry  of  metadata  change  requests,  track  the 
process  of  review  and  decision  by  distributing  to  reviewers  and  capturing 
responses,  report  the  status  of  each  request,  and  facilitate  the  review  process 

•  Reduce  redundancy  and  provide  a  common  foundation  for  shareable 
information 

•  By  providing  quality  metadata,  improves  developer  and  user  confidence  in 
the  enterprise  data  model 


Track 

Metadata 

Changes 


The  fleet  logistics  metadata  repository  enables  DA  to  track,  manage,  and  report 

the  status  of  metadata  changes  by  providing  the  following: 

•  Provide  configuration  management  for  models,  views,  logical  entities,  and 
data  elements,  with  capability  to  roll-back  and  spin-off  views  from  user- 
specified  versions  of  metadata 

•  Maintain  visibility  of  different  versions  of  model  items,  and  tracking  which 
version  is  in  use  by  which  model. 

•  Map  version  of  metadata  objects  to  versions  of  information  systems  where 
they  are  used 

•  Track  submittal,  review,  and  disposition  of  metadata  change  requests 


Continued  on  next  page 
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6.2.  Metadata  Repository  Requirements,  continued 


Repository  The  following  E-R  diagram,  shown  in  Figure  6-1 ,  shows  the  three  levels  of 
Metamodel  metadata  in  the  fleet  logistics  metadata  repository: 

•  Conceptual  data  architecture:  describes  the  kinds  of  information  that  are  of 
interest  to  the  fleet  logistics  enterprise. 

•  Logical  data  model:  describes  the  logical  entities  and  data  elements  of  the 
enterprise  in  a  manner  that  is  independent  of  any  application  system  or 
physical  database  design. 

•  Physical  data  model:  describes  the  implementation  of  the  logical  data  model 
in  the  physical  database  designs  of  fleet  logistics  standard  application 
systems. 

This  three-tier  approach  is  described  in  greater  detail  in  Appendix  A. 

Note:  This  model  does  not  match  any  specific  commercial  repository  software  product.  It 
represents  the  requirements  for  three  levels  of  metadata  needed  by  the  DA  repository 
function.  Implementation  may  require  a  series  of  closely  linked  tools  rather  than  use  of  a 
single  product. 


Physical  Data  Model 

Figure  6-1.  Three-Level  Metadata  Repository  Model 


The  following  paragraphs  describe  each  of  the  elements  of  the  metadata 
repository  model. 


Continued  on  next  page 
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Metadata  Repository  Requirements,  Continued 


Repository  The  following  items  each  explain  one  'meta-entity'  shown  in  Figure  6-1.  Each 
Meta-Entities  paragraph  provides  a  functional  description  of  its  respective  meta-entity,  and 
describes  the  functional  relationships  indicated  in  the  diagram.  The  diagram 
represents  a  logical  data  model  of  the  typical  metadata  repository  and  also 
reflects  the  working  relationships  of  the  various  elements  of  the  fleet  logistics 
data  administration  program. 

Information  Subject  areas  are  groups  of  information  classes.  Subject  areas  form  the  highest 

Subject  Area  abstraction  level  of  the  conceptual  data  architecture.  An  information  subject  area 

relates  to  a  CG  function  or  mission  area.  A  subject  area  may  include  one  or 
several  information  classes. 


Information 

Class 


Information  classes,  and  how  information  is  allocated  into  classes,  is  the  basis  of 
the  conceptual  data  architecture.  An  information  class  is  a  well-defined  category 
of  CG  information.  Each  information  class  represents  a  top-level  entity  in  the 
CG  enterprise  data  model.  Each  logical  entity  belongs  to  one  information  class. 
Each  information  class  is  designated  by  a  prime  word,  which  must  appear  in  the 
name  of  each  data  element  that  belongs  to  the  information  class.  A  data  steward 
and  subject  matter  experts  (as  needed)  are  assigned  to  support  an  information 
class. 


Data  Steward  A  data  steward  is  assigned  to  monitor  one  or  more  information  classes,  and  is 
responsible  for  the  technical  validity  and  enterprise  view  of  the  data  elements 
within  the  assigned  information  class.  Each  data  steward  is  familiar  with  the  CG 
information  systems  that  create,  update,  or  use  information  in  the  assigned 
information  class.  Stewards  model  the  use  and  flow  of  that  information, 
participate  in  the  setting  of  standards  and  process  improvement,  recruit  and 
coordinate  subject  matter  experts,  review  metadata  change  requests,  monitor  data 
quality,  and  represent  related  user  communities.  These  data  stewardship 
functions  are  described  in  Section  9. 


Logical  Entity  A  logical  entity  is  the  general  term  for  a  person,  place,  thing,  concept,  event,  or 
activity  about  which  the  enterprise  wishes  to  keep  information.  A  logical  entity 
is  used  for  data  modeling.  A  logical  entity  may  have  instances  in  specific 
applications  where  a  different  name  is  used  in  the  physical  database  design,  but  is 
mapped  to  the  logical  entity.  Pointers  in  this  entity  should  provide  for  logical 
entity  subtypes  and  versions.  Logical  entities  are  defined  from  an  enterprise 
point  of  view.  The  difference  between  physical  and  logical  data  is  explained  in 
Section  4  and  Appendix  A. 
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6.2.  Metadata  Repository  Requirements,  Continued 


Prime  Word  In  a  data  element  name,  the  prime  word  refers  designates  the  information  class  or 
high-level  entity  to  which  the  data  element  belongs.  It  is  typically  the  first  word 
in  a  data  element  name.  By  the  prime  word  the  data  element  name  indicates 
which  data  steward  is  the  primary  technical  reviewer  for  the  data  element. 


Entity 

Attribute 


While  a  logical  entity  represent  a  general  type  of  information  (such  as  name, 
vessel,  or  purchase  order  item),  each  entity  has  one  or  more  details  (atomic  facts) 
that  make  up  the  complete  set  of  information  about  the  entity.  Each  of  these 
attributes  at  the  logical  level  is,  in  the  next  phase,  further  defined  to  become  a 
standard  data  element. 


Standard  Data  A  standard  data  element  is  an  entity  attribute  that  has  been  more  rigorously 
Element  defined  with  a  set  of  data  element  attributes.  Along  with  business  process 

modeling  and  logical  data  modeling,  the  definition  of  standard  data  elements 
provides  the  basis  for  reliable  enterprise-wide  data  sharing.  Section  4  describes 
the  data  element  standardization  process. 


Source  Data  A  source  data  standard  is  a  clearly  defined  reference  from  which  to  obtain  values 
Standard  for  one  or  more  standard  data  elements. 


Element 

Group 


An  element  group  is  a  collection  of  standard  data  elements,  either  from  an  entity 
or  from  a  number  of  entities  whose  relationship  has  been  defined.  An  element 
group  is  a  logical  concept  that  is  used  by  application  designers  to  identify 
information  that  is  associated  in  a  specific  view  of  the  data,  but  may  not  belong 
to  the  same  entity. 


Registration  A  registration  transaction  is  an  event  where  a  version  of  a  piece  of  metadata 
Transaction  (such  as  a  standard  data  element  definition)  is  entered  as  a  candidate  definition, 
or  is  modified,  approved,  or  archived.  Each  transaction  record  designates  a 
change  in  status  and  version  of  a  piece  of  standard  metadata.  This  entity 
therefore  serves  both  as  a  pointer  to  current  data  values  and  as  a  configuration 
management  and  audit  trail  tool. 


Continued  on  next  page 
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6.2.  Metadata  Repository  Requirements,  Continued 


Data  Type  Each  data  element  represents  data  of  a  specific  type,  such  as  character,  number, 
date,  binary  object,  etc.  The  data  type  is  an  attribute  of  each  standard  data 
element. 

Class  Word  A  class  word  is  a  required  component  of  each  standard  data  element  name  that 
indicates  the  general  kind  of  information  (identifier,  text,  number,  or  date,  for 
example)  that  is  contained  in  the  standard  data  element's  values. 

Valid  Value  Each  standard  data  element  has  as  part  of  its  definition  a  set  of  acceptable  data 

Domain  values  (domain).  A  data  element's  domain  of  valid  values  may  be  infinite  (such 

as  a  numeric  field  of  variable  length)  or  specific  (a  set  of  transaction  codes). 

Relationship  The  logical  data  model  is  composed  of  logical  entities  and  definition  of  the 

relationships  between  entities.  These  relationships  reflect  the  business  rules  that 
govern  the  values  of  specified  data  elements.  This  entity  provides  for  definition 
of  these  links.  It  also  provides  for  recording  the  implementation  in  physical 
databases  of  these  relationships. 

Data  Model  The  values  of  this  entity  identify  the  logical  data  models  that  are  part  of  or 

derived  from  the  enterprise  data  model.  Its  links  identify  the  logical  entities  that 
each  model  includes.  These  models  can  represent  different  views  of  the  same 
logical  entities,  and  can  be  linked  to  application  databases. 

Application  The  values  of  this  entity  are  the  names  (and  other  identifiers)  of  each  database  or 

System  or  application  system  for  which  use  of  the  standard  metadata  is  recorded.  Linked  to 

Database  "physical  file,"  this  information  permits  where-used  analysis  to  determine  the 

effect  of  proposed  changes. 

Physical  File  A  physical  file  is  a  data  file  (table)  that  contains  data  values.  Typically,  a  group 
of  physical  files  and  the  relationships  between  the  data  in  these  files  constitute  a 
physical  database. 

Physical  Data  A  physical  data  field  is  a  physical  occurrence  of  a  standard  data  element  (which 

Field  is  also  an  entity  attribute).  It  is  a  column  in  a  table  or  a  field  in  a  file. 


Maintain  Metadata  Repository 


6.3.  Operations  on  Data  Models 


Introduction  The  following  functions  are  the  minimum  repository  capabilities  required  to 
perform  data  model  operations. 

Fleet  logistics  DA  obtains  metadata  from  outside  sources  and  uses  this 
information  to  develop  standard  logical  entities  and  data  elements,  and  to 
validate  and  enhance  data  element  definitions  and  attributes.  Processes  for 
receiving,  analyzing,  and  using  metadata  from  other  functions  and  organizations 
include  the  following: 

1 .  Receiving  a  data  model  from  sources  other  than  the  repository  tool,  such 
as  a  DBMS  data  dictionary,  a  database  report,  diagramming  tool,  or  other 
CASE  tool. 

2.  Translating  the  metadata  from  the  tool  in  which  it  was  developed,  and 
importing  the  model  into  the  repository's  analysis  software  using 
standard  or  customized  import  procedures.  This  metadata  is  used  by  data 
administration  staff  and  data  stewards  to  develop,  refine,  and  validate 
standard  data  element  definitions,  logical  entities,  and  information 
classes. 

3.  After  the  metadata  from  an  imported  data  model  is  incorporated  and 
naming  and  definition  differences  are  resolved,  then  this  information  can 
be  used  in  analysis  of  the  use  of  specific  data  by  various  standard, 
legacy,  and  other  organizations'  information  systems. 

Note  that  importing  a  legacy  system's  data  model  is  for  analysis  only.  This 
import  and  analysis  task  does  not  endorse  the  legacy  system  as  a  standard  system, 
nor  does  it  indicate  acceptance  of  the  legacy  system's  data  element  names  nor 
definitions. 


Refer  to  the  sections,  "Support  Development  and  Integration  of  Data  Models," 

"Share  Data  by  Mapping  and  Migration,"  and  "Maintain  Other  Models  and 
Definitions"  for  additional  information  regarding  utilization  of  metadata  in  the 
fleet  logistics  metadata  repository. 

Continued  on  next  page 
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6.3.  Operations  on  Data  Models,  Continued 


Select/  The  repository  software  must  support  selection  and/or  extraction  a  set  of 

Extract  a  Sub-  repository  objects  (sub-model)  based  on  specifications  from  an  analyst,  and 
Model  generates  a  new  sub-model  from  these  objects  for  use  in  other  development  work. 

Generate  Data  The  repository  software  must  support  generation  of  a  lower  level  data  model 
Model  /  from  the  repository  for  the  use  in  a  development  project. 

Database 

Schema  Current  standard  models  must  be  provided  early  in  the  planning  and 

requirements-setting  phases  of  a  new  development  or  upgrade  project. 

Provided  with  the  current  standard  data  model,  developers  should  avoid  creation 
of  an  independent,  incompatible  data  model. 

Develop  The  repository  software  must  support  generating  a  subset  of  the  standard 

Applications  enterprise  data  model  from  the  repository  for  the  use  of  an  analysis,  maintenance. 
Using  the  or  development  project. 

Data  Model 

The  available  formats  for  delivery  of  electronic  versions  of  the  standard  data 
model  will  depend  on  the  capabilities  of  the  repository  tool,  when  selected. 
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6.4.  Operations  on  Data  Elements 


Introduction  The  following  functions  are  the  minimum  repository  function  set  required  to 
manage  standard  data  elements. 

Create  a  The  repository  software  must  support  creation,  modification,  deletion,  and/or 

Standard  Data  submittal  of  proposed  data  elements  to  fleet  logistics  DA  for  approval.  The 
Element  request  tracking  part  of  the  repository  must  record  the  request  life  cycle  stages  as 

described  in  Sections  3  and  4. 


Map  Data  The  repository  software  must  support  mapping  of  standard  logical  data  elements 

Elements  to  the  physical  fields  in  legacy  systems,  with  aliasing.  This  feature  set  should 

support  the  mapping  and  migration  functions  described  in  Section  5. 


Analyze  Data  The  repository  software  must  support  analysis  of  potential  conflicts  between  data 
Element  elements  and  entity  attributes  based  on  their  similarities  and  differences.  The 

Conflicts  repository  tool  will  provide  capabilities  to  identify  data  element  conflicts  which 

take  the  following  forms: 

•  Same  name  and  definition  (redundancy),  same  name  and  different  definition, 

•  Same  definition  and  different  name  (potential  redundancy), 

•  Same  name  and  definition  with  different  entity  association. 
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6.5.  Operations  on  Other  Repository  Objects 


Introduction  The  following  functions  are  the  minimum  function  set  required  to  perform 
operations  on  repository  objects  other  than  data  models  and  data  elements. 


Link  The  repository  software  must  link  newly  loaded  repository  objects  (usually 

Repository  entities  and  relationships)  to  correspondent  objects  in  other  data  models  (higher 
Objects  level  models  or  previous  versions). 


Clone  The  repository  software  must  support  cloning  of  repository  objects  (usually 

Repository  entities,  relationships,  attributes)  to  correspondent  objects  in  other  data  models. 

Objects 


Assign 

Repository 

Object 

Ownership 


The  fleet  logistics  standard  data  model  is  a  passive  repository,  controlled  by  fleet 
logistics  DA.  The  repository  software  must  support  multiple  repositories,  so  that 
a  project  can  extract  the  required  subset  (view)  into  a  separate  model  for  analysis. 
Within  this  subset  view  only,  the  repository  software  must  support  assignment  of 
ownership  of  the  repository  objects  to  projects.  This  enables  owners  of  the 
subset  copy  to  make  changes  without  affecting  the  standard  metadata. 


Register  The  repository  software  must  support  registration  of  inconsistencies  within  or 

Metadata  between  models.  DA  will  use  this  feature  to  facilitate  review  of  logical  and 

Issues  attributed  data  models  that  are  submitted  by  developers  and  maintainers. 


Register  The  repository  software  must  support  registration  of  changes  to  the  metadata. 

Metadata  including  requests  for  changes  and  release  of  approved  changes. 

Changes 


Identify  The  repository  software  must  support  identification  of  impacts  of  metadata 

Change  changes  within  one  or  many  models.  This  “where-used”  report  will  be  used  by 

Impacts  DA,  data  stewards,  developers,  and  information  users. 


Propagate  The  repository  software  must  support  determination  of  inconsistencies  between 

Metadata  the  submitted  candidate  model  or  model  version  and  linked  objects  in  the 

Changes  standard  logical  data  model,  and  recommend  necessary  changes  in  the  linked 

objects. 
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6.6.  Additional  Repository  Utilities 


Introduction  The  following  repository  utilities  optimize  the  performance  of  the  required  data 
repository  functions.  Repository  tool  users  should  make  use  of  the  query  and 
report  functions  before  making  any  changes  to  the  current  model  and/or  data 
elements.  Electronic  mail  facilitates  communications  among  developers  and  fleet 
logistics  DA,  helping  to  ensure  that  change  proposals  are  more  accurately 
prepared.  The  repository  tool  system  administration  functions  are  vital  in 
ensuring  that  both  the  tool  and  the  repository  operate  continuously  and  reliably. 


Display 
Metadata  for 
User  Query 


The  repository  software  must  support  user  queries  of  data  elements  and/or 
entities  in  the  repository  based  on  the  following  criteria: 

•  Class  word 

•  Data  element  name 

•  Approval  status 

•  Prime  word 

•  Data  steward 


Generate 

Repository 

Reports 


The  repository  software  must  support  user  generation  of  reports  on  the  repository 
content.  Reports  are  based  on  any  or  all  of  the  following  criteria: 

•  Class  word 

•  Data  element  name 

•  Approval  status 

•  Prime  word 

•  Data  steward 


Electronic  The  repository  software  must  support  user  communication  through  an  electronic 

Mail  mail  system.  This  mail  system  will  facilitate  informal  discussion  on  current 

repository  issues,  resolution  of  small  problems,  coordination  of  meetings  and 
reviews,  and  recognition  of  opportunities. 


Continued  on  next  page 
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6.6. 


Additional  Repository  Utilities,  continued 


Repository 
Tool  System 
Administra¬ 
tion 


The  repository  tool  system  administrator  provides  technical  support  to  ensure  the 
integrity  of  the  tool.  System  administration  functions  for  the  repository  tool 
include: 

•  Backup,  archive,  and  recovery  procedures  in  case  of  a  computer  crash  or 
other  technical  difficulty 

•  User  account  administration  (granting  accounts,  restricting  access  to  the  tool, 
and  permission  to  create  or  modify  subset  views) 

•  Batch  job  support  for  large  data  input 

•  Ad-hoc  technical  support  in  the  form  of  robust  HELP,  online  manuals,  and/or 
function-specific  electronic  performance  support. 
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CONTROL  CHANGES  TO  METADATA 


7.1.  Overview 


Purpose  This  section  describes  the  processes  for  identifying  versions  of  and  controlling 

changes  to  the  various  types  of  metadata  in  the  fleet  logistics  data  repository.  It 
describes  the  working  relationship  between  data  defined  under  the  standards  for 
fleet  logistics  data  administration  (DA)  and  data  defined  elsewhere.  Data  defined 
elsewhere  includes  those: 

•  in  existing  systems, 

•  in  systems  developed  in  Coast  Guard  (CG)  organizations  outside  of  fleet 
logistics,  and 

•  in  systems  of  organizations  outside  of  the  CG. 


In  this  Section  This  section  includes  the  following  subsections: 


Topic 

Section 

Overview 

7.1 

Metadata  Change  Control  Process 

7.2 

Changes  to  Standard  Process  and  Data  Models 

7.3 

Updating  Standard  Data  Element  Names  &  Definitions 

7.4 

Changes  to  Application-Specific  Metadata 

7.5 

Changes  to  Standard  Term  Definitions 

7.6 

Changes  to  Other  Metadata 

7.7 

Continued  on  next  page 
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7.1.  Overview,  Continued 


Maintaining  Maintaining  metadata  is  required  in  various  tasks  to  propose,  review,  identify,  and 
Metadata  implement  changes.  In  an  enterprise-wide  data  resource,  changes  affect  the  entire 

community,  not  just  one  application  system.  The  processes  in  this  section  show 
that  diverse  teams  developing  information  systems  can  propose  changes 

•  to  the  same  enterprise  data  model, 

•  to  standard  data  elements,  and 

•  to  definitions 

and  that  the  changes  can  be  reviewed  and  implemented  in  an  organized  and 
controlled  manner. 

In  addition,  since  metadata  from  legacy  systems  needs  to  be  referenced,  an 
abbreviated  form  of  the  metadata  maintenance  process  is  addressed. 


Importance  of 

Enterprise- 

Wide 

Consistency 


For  data  to  be  shared  reliably  and  usefully,  the  definitions  and  characteristics  of 
entities  and  data  elements  must  be  absolutely  consistent.  In  the  long  term  it  is 
intended  to  have  all  information  systems  comply  with  standards.  In  the  meantime, 
data  must  be  shared  with  existing  systems,  built  to  different  standards  or  designed 
their  respective  data  structures  without  regard  to  external  standards.  Sharing  data 
among  non-standard  systems  requires  careful  analysis  of  the  metadata  of  those 
systems.  Fleet  logistics  DA  provides  a  repository  for  metadata,  including  metadata 
from  systems  that  are  not  fleet  logistics  standard.  However,  these  non-fleet 
logistics  standard  metadata  will  be  identified  as  such,  so  that  there  is  no  confusion 
with  the  fleet  logistics-standard  metadata.  This  repository  provides  a  central  point 
for  reference  and  interface  work. 


While  interim  solutions  are  necessary  on  occasion,  the  intent  of  the  CG  is  to  work 
toward  open  systems  -  that  is,  systems  using  standard,  sharable  data. 


Continued  on  next  page 
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7.1. 


Overview,  continued 


Metadata 
Subject  to 
Change 
Control 


The  term  'metadata'  includes  models,  model  objects,  and  definitions  that  are  used 
to  describe  data.  DA  is  interested  primarily  in  the  metadata  that  make  up  the 
standard  for  the  fleet  logistics  standard  information  resource.  DA  also  supports  the 
fleet  logistics  community  by  providing  a  central  point  for  storing  and  referencing 
metadata  that  describe  data  used  by  legacy  systems,  systems  of  allied  agencies,  and 
other  non-standard  information  systems.  The  following  types  of  metadata  are 
subject  to  change  control,  and  the  revisions  are  used  to  keep  the  fleet  logistics 
repository  current: 

•  Standard  process  and  data  models 

•  Standard  logical  entities,  relationships,  and  data  element  definitions 

•  Fleet  logistics  application-specific  (non-standard)  data  and  process  models  and 
model  objects 

•  Standard  term  definitions 

In  addition,  the  following  types  of  metadata  can  be  put  under  change  control  in  this 
repository,  if  desired  by  the  developer/user  organization: 

•  Metadata  from  systems  of  allied  agencies 

•  Metadata  standards  of  allied  agencies,  industry,  and  standards  organizations 

•  CG-wide  process  and  data  models 


Repository  for  For  systems  that  are  not  yet  registered  as  standard  systems,  the  fleet  logistics  DA 
Application-  repository  will  accept,  for  reference  purposes  only,  process  models,  data  models. 
Specific  schemas,  physical  database  designs,  definition  of  key  terms,  and  other  metadata. 

Metadata  The  purposes  for  keeping  this  information  is  to  provide  a  central  reference  point 

for  planning  of  future  interfaces  to  non-standard  systems,  and  to  validate  the 
completeness  and  applicability  of  standard  definitions. 


Definition  of 

Standard 

Terms 


For  definitions  to  be  comparable  and  to  improve  the  success  rate  for  comparing 
and  reconciling  data  definitions,  a  set  of  standard  terms  shall  be  used  where 
applicable.  The  current  dictionary  of  standard  terms  is  provided  in  Appendix  B, 
Class  Word  Descriptions. 


Continued  on  next  page 
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7.1.  Overview,  Continued 


Baseline  and  The  change  control  process  calls  for  submittal  of  each  validated  version  of  the 

Version  model  to  CM  for  archiving  and  version  control.  Each  version  of  the  model  that  is 

Control  released  for  use  outside  the  project  team  should  be  released  through  CM  and 

assigned  an  incremental  version  number. 


The  first  released,  approved  version  of  the  attributed  data  model  will  become  the 
data  model's  baseline,  and  will  be  numbered  Version  1.0.  Subsequent  minor 
adjustments  and  corrections  will  be  assigned  minor  version  numbers  (1.1, 1.2, 
etc.).  Major  redesigns  will  be  numbered  with  the  next  major  revision  number  (2.0, 
3.0,  etc.). 


Who 

Requests 

Metadata 

Changes? 


The  most  typical  generators  of  change  requests  are  development  teams  (who  have 
uncovered  or  refined  a  requirement)  or  data  users  (who  need  an  adjustment  to  meet 
information  needs).  Other  potential  contributors  are  the  data  stewards  (whose 
business  processes  or  regulatory  requirements  often  change)  and  fleet  logistics  DA 
staff  (who  detect  inconsistencies,  propose  new  standards,  and  respond  to  changes 
in  the  standards  of  allied  organizations). 
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7.2.  Metadata  Change  Control  Process 


Purpose  This  subsection  describes  the  process  to  control  changes  to  the  various  types  of 

metadata  included  in  the  fleet  logistics  metadata  repository. 


General 

Responsibi¬ 

lities 


To  maintain  the  integrity  and  usability  of  metadata,  any  changes  to  it  to  create  new 
versions  must  be  controlled.  This  control  is  a  shared  responsibility.  Developers 
prepare  and  submit  valid  versions,  DA  tracks  the  changes,  the  repository  software 
assigns  version  numbers  automatically;  and  DA  makes  available  the  current  and 
valid  versions  of  standard  metadata.  DA  ensures  that  the  change  request  is 
technically  correct  and  then  notifies  CM  of  the  readiness  of  the  change  for  release. 
CM  releases  the  change. 


In  addition,  DA  receives  and  catalogs  copies  of  metadata  from  non-standard 
systems  is  for  reference  and  planning. 


Process  Each  type  of  metadata  requires  certain  variations  and  emphasis  of  the  basic 

Overview  management  process.  These  variations  are  described  in  the  following  subsections. 

The  common,  basic  process  consists  of  the  following  steps: 


Step 

Action 

1 

Preparation  -  Developer  prepares  change  request 

2 

Submittal  -  Developer  transmits  request 

3 

Receipt  -  Fleet  logistics  DA  receives,  logs,  and  checks  request 

4 

Review  -  Request  reviewed  for  standards,  function,  and  effect 

5 

Disposition  -  Fleet  logistics  DA  accepts,  rejects,  or  requests  modification 

6 

Release  -  Fleet  logistics  DA  authorizes  change;  CM  releases 

7 

Implementation  -  Change  repository;  notify  community 

Continued  on  next  page 
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7.2.  Metadata  Change  Control  Process,  continued 


General  This  general  process  shows  the  fleet  logistics  DA  approach  to  maintaining 

Process  for  metadata.  The  detail  for  preparing,  submitting,  checking,  and  implementing 

Updating  changes  for  each  type  of  metadata  is  provided  in  the  remaining  subsections. 

Metadata 

Figure  7-1  shows  the  tasks  associated  with  each  of  the  metadata  management 
phases. 


Requirements 

Technology  \  Metadata 


Developer, 
User,  or 
Steward 


Fleet  Logisti^ 

Data  Admini^tion 


\  Metadata 


Interfaces 


Preparation 

r 

Submittal 

■  n  a 

1 

r 

Receipt 

1 

r 

Review 

f 

Data  Standards 

Data  Steward(s) 

Development  team,  user,  or  data  stevi^ard 
compiles  and  prepares  change  request 

Developer  project  management 
or  data  steward  approves  request 

Developer/User/Steward  transmits  request 


DA  administration  receives  &  logs-in  request 
DA  analyst  checks  request  for  completeness 


DA  analyst  reviews  request  for  metadata  standards, 
coordinates  name  &  definition  with  CG  DA 

Assigned  data  steward(s)  assesses  effect  of  change 
Data  steward(s)  assesses  technical  accuracy  of  change 

Steward  consults  Subject  Matter  Expert(s) 

Stewardship  Recommendation:  Accept,  Reject,  or  Modify 


DA  evaluates  Data  Standards  and  Data  Steward  findings 
DA  responds:  Accept,  Reject,  or  Modify 

DA  analyst  prepares  draft  notice 

DA  signs  release  notice 
Implementors  notified  to  proceed 

Enterprise  community  notified  of  change 
Change  implemented  in  repository 


Figure  7-1.  Change  Request  Review  and  Disposition  Process 


Continued  on  next  page 
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7.2.  Metadata  Change  Control  Process,  continued 


Preparation  of  The  decision  to  request  a  change  in  metadata  can  come  about  from  a  combination 

Change  of: 

Request 

•  Changes  or  refinements  in  application  requirements 

•  Changes  in  tools  and  software  environments,  or  in  requirements  to  move 
metadata  between  tools 

•  Metadata  of  systems  from  outside  of  fleet  logistics  with  which  a  fleet  logistics 
system  must  share  data 

The  developer  must  consolidate  the  requirements  into  a  specific  set  of  changes, 
which  the  developer  then  submits  as  a  change  request.  Generally,  a  change  request 
contains  the  following  types  of  information: 

•  Identification  of  the  system  and  program  that  generated  the  requirement  for  the 
change 

•  Identification  of  the  standard  (or  application-specific)  metadata  to  be  changed 

•  Complete  description  of  the  change,  reduced  to  remove-and-replace  steps 

•  Explanation  of  the  requirement  for  the  change 

•  Developer's  estimate  of  the  effect  of  the  change,  and  the  effect  of  not  making 
the  change 

•  Scheduling  information 

The  format  and  level  of  detail  for  each  of  these  types  varies  by  type  of  metadata,  as 
indicated  in  the  following  subsections.  Each  request  package,  however,  must 
address  each  of  these  points. 


Submittal  of  The  developer  should  route  metadata  change  requests  through  the  application's 
Change  program  management  and  configuration  management  functions,  so  that  the  request 

Requests  reflects  the  requirements  of  the  program. 


The  developer  organization  transmits  the  request  package  to  fleet  logistics  DA. 


Continued  on  next  page 


7-7 


Control  Changes  to  Metadata 


7.2.  Metadata  Change  Control  Process  continued 


Analysis  and  Upon  receipt  of  a  request  package,  DA  performs  the  following  intake  process: 

Disposition 


Step 

Action 

1 

Log-in  the  package 

2 

Check  package  for  completeness  (return  if  incomplete) 

3 

Check  the  cited  metadata  for  applicability  of  the  requested  change  (Has 
it  already  been  changed?  Is  the  requester  applying  the  change  to  the 
correct  version?  Does  the  "change  from"  information  exist?) 

4 

Standards  compliance:  format  and  completeness  (Does  the  requested 
change  conform  to  the  data  standard(s)  for  the  type  of  metadata?) 

5 

Discrepancy  resolution  (request  correction  of  minor  discrepancies  by 
memo,  electronic  mail,  or  telephone;  return  package  for  major 
corrections) 

6 

Accept  corrected  request  package  for  review.  Notify  DA  and  the 
requesting  developer  of  the  start  of  the  review  process 

For  submittals  regarding  application-specific  (non-standard)  systems,  the  review 
for  completeness  is  the  only  step  needed  for  acceptance.  Only  metadata  that  will 
be  integrated  into  the  fleet  logistics  enterprise  model  is  subject  to  the  review 
process. 


Review  Review  of  the  change  request  is  intended  to  answer  three  questions: 

•  Will  the  change  cause  the  metadata  to  remain  standard  or  alter  its  level  of 
quality?  (Standards  review) 

•  Does  the  proposed  change  enhance  the  accuracy,  relevance,  and  usefulness  of 
the  standard  entity,  element,  or  definition?  (Data  stewardship  review) 

•  What  will  be  the  effect  on  other  systems,  programs,  and  mission  areas  that  use 
the  same  metadata?  (Impact  analysis  review) 

Fleet  logistics  DA  coordinates  these  three  reviews,  and  uses  the  results  to  act  on 
the  change  request. 

When  this  review  finds  standards,  technical,  or  usage  problems  with  the  change 
request,  DA  will  issue  a  Metadata  Discrepancy  Report  for  each  item.  The  report 
form  is  provided  in  Appendix  D. 


Continued  on  next  page 
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7.2.  Metadata  Change  Control  Process  continued 


Standards  Data  standards  review  is  performed  by  fleet  logistics  DA.  The  purpose  of  this 
Review  review  is  to  ensure  that  the  proposed  change  is  consistent  with  data  description, 

quality,  and  security  standards.  This  is  different  from  the  preliminary  check  in  that 
it  examines  the  metadata  before  and  after  the  proposed  change,  rather  than  just 
checking  the  format  and  content  of  the  change  request  package.  In  addition,  the 
standards  reviewer  identifies  the  data  steward(s)  that  will  perform  the  data 
stewardship  review. 

Standards  review  points  are  documented  in  Sections  3,  Support  Development 
and  Integration  of  Data  Models,  4.,  Standardize  Data  Elements,  and  8,  Ensure 
Data  Quality.  The  standards  reviewer  assesses  the  effect  of  the  proposed  change 
from  a  metadata  standards  point  of  view,  and  provides  a  recommendation  to  fleet 
logistics  DA. 

A  metadata  change  request  will  be  distributed  for  stewardship  review  only  after  all 
discrepancies  found  in  the  standards  review  have  been  resolved. 


Continued  on  next  page 
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7.2.  Metadata  Change  Control  Process  continued 


Data  Data  stewardship  review  is  performed  by  experts  within  the  mission  area  that 

Stewardship  supports  the  information  class  of  the  proposed  change.  The  purpose  of  the  data 

Review  stewardship  review  is  to  assess  the  technical  merit  and  the  enterprise-wide  effects 

of  the  proposed  change  from  a  mission  area  perspective.  Some  change  requests 
will  require  assessment  by  more  than  one  mission  area. 

The  stewardship  reviewer(s)  should  answer  the  following  questions: 


Step 

Question 

1 

Do  the  proposed  changes  in  definition,  codes,  fields,  and/or  other 
characteristics  accurately  describe  the  intended  information,  in  its  best 
use?  "Best  use"  means  effective  implementation  of  CG  policy  and 
practice,  achieving  the  objectives  of  the  mission  area,  and  best 
professional  practice. 

2 

Does  the  change  include  and  support  business  rules,  access  control, 
validity  checking,  and  synchronization  that  will  ensure  the  consistency, 
quality  and  reliability  of  the  data  values? 

3 

When  the  metadata  is  modified  by  the  proposed  changes,  will  the 
standard  entity,  element,  and/or  definition(s)  still  meet  all  regulatory, 
policy,  quality,  and  security  requirements? 

4 

What  current,  developing,  and  planned  standard  systems  will  this  change 
affect,  and  what  work  must  be  done  in  these  other  systems  to 
accommodate  the  change? 

5 

Taking  into  account  the  revision  and  release  schedules  of  the  other 
affected  systems,  program  requirements,  and  other  changes  that  are 
occurring  or  planned  within  the  mission  area,  what  is  the  most  effective 
date  for  this  change  to  be  implemented? 

The  data  stewardship  reviewer(s)  assesses  the  effect  of  the  proposed  change  from  a 
subject  matter  expert  point  of  view  and  as  a  representative  of  the  mission  area  that 
is  responsible  for  the  information  class.  From  this  assessment,  he/she  provides  a 
recommendation  to  DA.  The  steward’s  findings  may  include  one  or  more 
Discrepancy  Reports. 

Data  stewardship  review  process  is  described  in  Section  9.3.  A  form  is  provided 
in  Appendix  D  for  data  stewardship  review  response. 


Continued  on  next  page 
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7.2. 


Metadata  Change  Control  Process  continued 


Disposition  Fleet  logistics  DA  reviews  the  recommendations  and  determines  whether  to  accept, 
reject,  or  modify  the  proposed  change: 

•  DA  accepts  the  metadata  change  request  by  approving  it  and  transmitting  it  to 
CM. 

•  DA  rejects  the  request  by  returning  it  to  the  requesting  organization  with  a 
note  of  explanation. 

•  DA  indicates  the  need  to  modify  a  request  by  transmitting  Metadata 
Discrepancy  Report(s)  to  the  requesting  organization. 

Only  approved  change  requests  are  transmitted  to  CM. 


Release  and 
Implementa¬ 
tion  of 
Changes 


Notice  of  the  decision  is  transmitted  to  the  requesting  organization  and  to  other 
stakeholders  as  needed.  General  notice  of  changes  is  made  available  to  all 
interested  individuals  and  organizations. 

The  DA  transmits  the  approved  metadata  change  request  (after  modification  and 
review,  if  necessary)  to  CM  for  release.  After  release,  DA  transmits  the  change  to 
the  operator  of  the  repository  for  implementation. 
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7.3.  Changes  to  Standard  Process  and  Data  Models 


Purpose  This  section  describes  the  specific  preparation  and  review  actions  necessary  to 

revise  standard  fleet  logistics  process  and  data  models.  The  process  for  change 
request  submittal,  review,  and  disposition  is  described  in  the  previous  subsection. 
This  subsection  contains  the  additional  information  that  is  specific  to  revising 
process  and  data  models. 


Reasons  to 
Request 
Changes  in 
Standard 
Models 


Process  and  data  modeling  is  an  iterative  process.  Each  analysis  and  design  task 
provides  an  opportunity  to  add  more  detail  and  insight  to  the  current  process  and 
data  models.  Frequently  new  processes  and  data  entities  need  to  be  described. 
When  they  cannot  be  described  by  existing  standard  processes,  relationships,  and 
entities,  then  revisions  should  be  proposed. 


The  act  of  proposing  a  change  does  not  by  itself  ensure  acceptance  of  the  precise 
definition  and  characteristics  in  the  language  of  the  submitter.  Instead,  it  starts  a 
process  of  attention  by  DA,  functional  expert,  and  data  user  communities.  Out  of 
this  process  will  come  a  response  that  meets  the  original  need,  and  may  also 
address  enterprise-wide  issues  that  were  highlighted  by  the  original  request. 


Preparation 
and  Submittal 
of  Revised 
Models 


Revision  of  a  model  is  more  complex  than  revision  of  one  definition.  To  modify  a 
fleet  logistics  process  model  or  data  model,  one  must  propose  additions  or 
modifications  to  specific  entities  and  relationships,  not  to  the  entire  model. 
Evaluation  by  DA  will  be  based  on  these  individual  changes.  DA  will  determine 
the  full  impact  of  the  change  on  the  process  or  data  model,  and  take  appropriate 
steps  for  modifications  on  that  level. 


Continued  on  next  page 
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7.3.  Changes  to  Standard  Process  and  Data  Models, 

Continued 


Data 

Standards 

Evaluation 


DA  will  evaluate  process  and  data  model  changes  for  compliance  with  CG  data 
standards.  Any  discrepancies  will  be  recorded  and  tracked  by  fleet  logistics  DA 
using  the  Metadata  Discrepancy  Report  provided  in  Appendix  D.  DA  will  notify 
the  Data  Steward  after  data  standards  discrepancies  have  been  reconciled. 


Data 

Stewardship 

Evaluation 


Data  stewards  will  complete  a  Data  Steward’s  Review  Response  (provided  in 
Appendix  D)  for  each  review  request.  In  addition,  a  steward  may  complete  one  or 
more  Metadata  Discrepancy  Report(s)  when  he/ she  identifies  a  specific  issue  or 
problem  in  a  change  request. 


Data  stewards  will  evaluate  process  and  data  model  changes  from  the  viewpoint  of 
logistics-wide  or  CG-wide  business  processes,  not  from  the  viewpoint  of  the 
specific  application  system.  The  assumption  by  the  Data  Steward  reviewer  is  that 
this  change  is  in  compliance  with  CG  data  standards. 


Disposition 

and 

implementa¬ 
tion  of 
Changes 


When  accepted,  changes  will  be  incorporated  into  the  fleet  logistics  DA  corporate 
process  model  and  corporate  data  model.  These  procedures  are  described  in 
Section  3,  Integrate  Data  Models. 

After  metadata  changes  have  been  implemented  by  fleet  logistics  DA,  the 
repository  operator  assigns  a  version  number  to  the  change  and  notifies  all  systems 
affected  by  the  change.  These  procedures  are  also  described  in  Section  3, 
Integrate  Data  Models. 
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7.4,  Changes  to  Standard  Data  Element  Names  and 
Definitions 


Purpose  This  section  describes  the  specific  preparation  and  review  actions  necessary  to 

revise  fleet  logistics  standard  data  element  definitions.  The  process  for  change 
request  submittal,  review,  and  disposition  is  described  in  Section  7.2,  The  Change 
Control  Process.  This  subsection  contains  the  additional  information  that  is 
specific  to  revising  definitions  of  standard  data  elements. 


Reasons  to  Analysis  of  a  business  process  may  yield  refinements  in  a  data  element  definition. 
Request  Data  or  extensions  to  a  domain  or  attribute  set. 

Element 

Definition  Data  element  change  requests  can  be  submitted  as: 

Changes 

•  Add  a  new,  unique  data  element  (or  a  set  of  elements  for  a  new  entity) 

•  Modify  an  existing  standard  element 

•  Add  a  new  relationship  type,  or  modify  the  definition  of  an  existing 
relationship. 


A  separate  type  of  request  is  the  request  for  exemption  from  compliance  to  the 
standard  for  a  strictly  internal,  non-shareable  element. 


Preparation  Because  each  standard  data  element  belongs  to  one  entity,  clearly  identify  the 
and  Submittal  entity  to  which  the  data  element  belongs. 

of  Changes 

Since  some  data  element  reviewers  may  not  have  regular  on-line  access  to  the  fleet 
logistics  repository  system,  all  parts  of  the  change  request  package  must  be 
reducible  to  hard  copy,  even  for  requests  submitted  electronically. 


Data 

Standards 

Evaluation 


DA  will  evaluate  data  element  changes  for  compliance  with  CG  data  standards. 
Any  discrepancies  will  be  recorded  and  tracked  by  fleet  logistics  DA.  DA  will 
pass  the  change  to  the  Data  Steward  after  data  standards  discrepancies  have  been 
reconciled. 


Continued  on  next  page 


7-14 


Control  Changes  to  Metadata 


7.4,  Changes  to  Standard  Data  Element  Names  and 
Definitions,  continued 

Data  stewards  will  evaluate  data  element  changes  from  the  viewpoint  of  logistics 
Data  or  the  CG,  not  from  that  of  the  specific  application  system.  The  assumption  by  the 

Stewardship  Data  Steward  reviewer  is  that  this  change  is  in  compliance  with  CG  data  standards. 

Evaluation 

Section  9.3  describes  the  data  stewardship  review  process. 

Decision  and  Accepted  changes  will  be  available  (with  effective  date  noted)  in  the  fleet  logistics 
Implementa-  data  repository  within  a  reasonable  time  after  acceptance. 

tion  of 

Changes  Changes  will  be  integrated  into  the  fleet  logistics  corporate  data  model  within  a 

reasonable  time  after  acceptance. 
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7.5.  Changes  to  Application-Specific  Metadata 


Purpose  The  process  for  change  request  submittal,  review,  and  disposition  of  metadata  is 

described  in  Section  7.2,  The  Change  Control  Process.  This  section  contains  the 
additional  information  that  is  specific  to  revising  application-specific  (non¬ 
standard)  metadata. 


What 
Metadata 
should  be 
Submitted 
and  Updated? 


Other  process  and  data  models,  set  of  definitions,  or  other  metadata  may  be 
submitted  for  consideration  to  be  cataloged  and  stored.  As  the  resources  of  DA 
and  the  repository  increase  over  time,  the  set  of  other  metadata  considered 
acceptable  may  also  increase. 


Preparation  Updates  can  be  submitted  with  the  instructions  to  replace  previous  versions,  or  to 
and  Submittal  store  in  addition  to  previous  versions. 


Disposition  DA  does  not  act  on  application-specific  (non-standard)  metadata.  Responsibility  is 
by  DA  limited  to  cataloging  contributions  and  making  them  available  for  analysis  by 

developers  and  users  outside  of  fleet  logistics. 
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7.6.  Changes  to  Standard  Term  Definitions 


Purpose  The  process  for  change  request  submittal,  review,  and  disposition  of  metadata  is 

described  in  Section  7.2,  The  Change  Control  Process.  This  subsection  contains 
the  additional  information  that  is  specific  to  revising  standard  term  definitions. 

The  collection  of  these  definitions  is  referred  to  as  the  standard  terms  dictionary. 


Updating  of 
Standard 
Terms 
Dictionary 


Current  and  accurate  standard  terms  are  important  to  everyone  who  creates  and 
submits  definitions.  Use  of  standard  terms  in  definitions  facilitates  understanding 
and  review  of  submitted  metadata.  Submittal  of  new  terms  and  refinement  of 
existing  definitions  will  keep  the  standard  terms  dictionary  current  and  complete. 


Reasons  to 
Request 
Change  of  a 
Standard 
Term 


The  most  likely  reasons  to  submit  revisions  are: 

•  Refinement  needed  before  using  a  specific  definition  in  an  application 

•  No  reasonable  match  found  for  a  needed  term 

•  Current  standard  definition  creates  confusion  in  a  particular  context 

•  An  additional  meaning  for  a  standard  term  is  discovered. 


Every  word  that  is  used  in  any  definition  is  not  necessarily  a  candidate  for  the 
standard  terms  dictionary.  The  most  useful  additions  are: 

•  Technical  terms  and  phrases  that  have  specific  meaning  in  a  business  process 

•  Nouns  that  refer  to  specific  things  in  CG  use  and  might  be  misinterpreted  as 
more  general  things 

•  Adjectives  that  place  a  standard  noun  in  a  specific  context  or  condition 

•  Verbs  that  denote  specific  actions  or  processes 


Preparation 
and  Submittal 
of  Change 
Request 


A  standard  term  or  definition  request  should  include: 

The  standard  term  (new  or  proposed) 

•  Current  definition 

•  Proposed  definition 

•  Reason  for  the  change 

•  Estimate  of  the  instances  in  fleet  logistics  standard  metadata  where  the 
proposed  definition  will  be  used  (i.e.,  effect  of  making  this  change) 

•  Consequences  of  not  making  the  change 

•  Program  or  organization  generating  the  change,  with  contact  information 


Continued  on  next  page 
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Control  Changes  to  Metadata 


7.6.  Changes  to  Standard  Term  Definitions,  continued 


Analysis  and 
Review  of 
Change 
Request 


Analysis  and  review  of  standard  term  change  requests  should  follow  the  same 
pattern  as  review  for  other  items,  as  mentioned  in  this  subsection,  including:  Data 
Standard  Evaluation,  Data  Stewardship  Evaluation,  Disposition  and 
Implementation  of  Changes,  and  Incorporation  into  the  fleet  logistics  enterprise 
data  model. 
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7.7.  Changes  to  Other  Metadata 


Purpose  The  process  for  change  request  submittal,  review,  and  disposition  of  metadata  is 

described  in  Section  7.2,  The  Change  Control  Process.  This  subsection  contains 
the  additional  information  that  is  specific  to  revising  metadata  other  than  the  types 
described  in  the  previous  subsections. 


Preparation  Prepare  the  change  package,  noting  "not  applicable"  for  items  that  are  not 
and  Submittal  appropriate  for  the  type  of  metadata  being  changed.  Note  that  for  exceptions  and 
unusual  submittals,  it  is  especially  important  to  identify  precisely  the  subject  of  the 
change. 


Receipt  and  DA  will  log  and  evaluate  an  "other"  change  request  package  using  the  standard 
Processing  process.  DA  will  determine  the  review  process,  as  appropriate  to  the  request. 


Notice  to  In  addition  to  the  notice  specified  in  Section7.2,  fleet  logistics  DA  will  broadcast 

Community  notice  of  "other"  change  requests  shortly  after  receipt  of  the  request.  This 

additional  notice  is  to  alert  potential  stakeholders  of  a  potential  change  that  affects 
more  than  a  single  definition. 


SECTION  8 

ENSURE  DATA  QUALITY 


8.1.  Overview 


Introduction  This  section  provides  the  concepts  and  procedures  that  provide  data  quality  and 
security  components  to  the  data  administration  process.  These  processes  are  not 
separate,  but  are  integrated  into  the  system  life  cycle  and  metadata  development 
process.  The  quality  criteria  in  this  chapter  are  intended  to  be  applied  during 
development  and  subsequent  review  cycles. 

The  goal  of  the  processes  described  in  this  subsection  is  to  provide  for  quality 
and  security  of  the  data  through  design  and  planning.  These  functions  focus 
attention  on  the  development  and  business  processes  that  create  data  values,  and 
facilitate  authorized,  system-wide  sharing  of  information. 


In  this  Section  This  section  contains  the  following  topics: 


Topic 

Section 

Overview 

8.1 

Data  Quality  and  Security  Concepts 

8.2 

Ensuring  Compliance  with  Data  Standards 

8.3 

DA  Education  and  Outreach 

8.4 

Facilitation  and  Technical  Support 

8.5 

Processes  and  Criteria  for  Metadata  Review 

8.6 

Acceptance  and  Registration  of  Standard  Systems 

8.7 

Modifications  to  and  Exemptions  from  Data  Standards 

8.8 

Assess  Risk  and  Control  Access  to  Non-Public  Information 

8.9 

Risk  Analysis  Process 

8.10 

Ensure  System-Wide  Data  Synchronization 

8.11 

Ensure  Data  Quality  and  Integrity 

8.12 

Implement  Data  Integrity  Measures 

8.13 

Establish  Consistent  Definition  of  Terms  across  Systems 

8.14 

Improve  the  Data  Quality  Program 

8.15 

Continued  on  next  page 
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8.1.  Overview,  Continued 


Cross  The  following  table  indicates  topics  that  are  covered  in  specific  sections. 

Reference 


Topic 

Primary 

Responsibility 

Refer  to  Subsection 

Principles  and  concepts  for 
data  quality  and  security 

8.2.  Quality  and  Security  Concepts 

Compliance  with  metadata 
standards 

Fleet  logistics  DA 
staff 

8.3.  Ensuring  Compliance  with  Data 
Standards 

8.6.  Processes  and  Criteria  for 
Metadata  Review 

8.7.  Acceptance  and  Registration  of 
Standard  Systems 

Data  security. 

Data  ownership, 

Access  permissions 

Fleet  logistics  DA 
staff.  Data 
Stewards 

8.9.  Assess  Risk  and  Control  Access 
to  Non-Public  Information 

8.10.  Risk  Analysis  Process 

Data  synchronization 
Concurrent  update 

Timeliness 

Fleet  logistics  DA 
staff.  Data 
Stewards 

8.12.  Ensure  System-Wide  Data 
Synchronization 

Data  quality 

Data  integrity 

Validation  formulas 

Developer 

8.12.  Ensure  Data  Quality  and 

Integrity 

8.13.  Implement  Data  Integrity 
Measmes 

Implement  the  Program 
Enable  developers  to  use  the 
standard 

Enforcement 

Fleet  logistics  DA 
staff.  Data 
Stewards 

8.3.  Ensuring  Compliance  with  Data 
Standards 

8.4.  DA  Education  and  Outreach 

8.5.  DA  Facilitation  and  Technical 
Support 

Metadata  terms  and 
definitions 

Fleet  logistics  DA 
staff 

8.14.  Establish  Consistent  Definition 
of  Terms  across  Systems 

Program,  process 
improvement 

Community 

8.15.  Improving  the  Data  Quality 
Program 

Continued  on  next  page 
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8.1.  Overview,  Continued 


Background  Since  the  mid-1960's,  system  engineers  and  database  designers  have  recognized 
the  importance  of  data  management  to  ensure  high-quality  data.  Enterprise-wide 
integrated  information  systems  such  as  CG  fleet  logistics  require  thorough 
understanding  of  the  nature  of  data,  the  relationship  of  various  data  entities,  and 
the  use  of  data  by  each  application  system  and  business  process. 

Information  is  a  major  asset  to  any  organization.  Many  logistics  operations  are 
complex  and  data-intensive;  they  require  the  right  data  in  the  right  form  at  the 
right  time.  The  consequences  of  inaccurate,  late,  or  unusable  data  can  be 
significant  to  other  CG  missions.  High-quality,  shareable  data  is  a  force 
multiplier  and  economy  measure  because  it  supports  better  planning,  indicates 
opportunities  for  process  improvement,  locates  resources  and  identifies 
duplication,  and  enables  staff  to  make  faster,  better-informed  decisions. 

The  advantage  of  an  integrated  information  system  is  that  it  uses  the  combined 
information,  across  organizations  and  functions,  to  provide  current  and  complete 
information  to  each  of  its  application  systems.  This  advantage  is  threatened  if 
unauthorized  individuals  and/or  processes  can  read  and  misuse  or  change  items 
in  the  shared  data  resource,  if  data  characteristics  are  defined  inconsistently,  if 
data  values  are  corrupted  or  overwritten,  or  if  invalid  values  are  mixed  in  with 
valid  ones.  User  confidence  in  the  integrated,  enterprise- wide  data  resource 
deteriorates  and  the  data  sharing  concept  is  defeated  if  any  part  of  the  standard 
data  resource  becomes  unreliable  or  unusable. 


Data  Quality  Data  quality  is  the  capability  of  the  data  to  meet  the  expectations  and 

requirements  of  the  users.  High-quality  data  is  usable,  accurate,  complete, 
accessible,  reliable,  dependable,  unambiguous,  and  timely.  The  definitions  and 
attributes  of  data  elements  are  compatible  from  one  standard  system  to  the  next, 
permitting  reliable  data  sharing.  Data  ownership  and  limitations  to  access  are 
clearly  and  consistently  defined.  Careful  system  design,  data  administration,  and 
system  administration  are  critical  to  obtaining  and  keeping  high-quality  data. 

The  quality  of  the  data  in  these  terms  determines  the  value  of  shareable  data  to 
all  potential  users. 


Quality  of  Metadata  quality  refers  to  the  completeness,  accuracy,  portability,  and  ease  of 
Metadata  use  of  the  information  that  describes  and  standardizes  the  data.  Description 

includes  definition,  format  attributes,  business  rules,  ownership  information, 
access  restrictions,  synchronization,  integrity  tests,  and  use  of  standard  terms. 
High-quality  metadata  includes  clear  definitions,  attributes  that  support  how  the 
data  values  will  be  used  in  the  real  world,  support  for  data  sharing  with  the 
desired  applications  and  organizations,  and  sufficient  planning  and  foresight  to 
meet  the  needs  of  all  potential  users  of  the  information. 


Continued  on  next  page 
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8.1.  Overview,  Continued 


Quality  of  Quality  of  the  physical  data  (values)  is  determined  by  the  usefulness,  reliability. 
Physical  Data  accuracy,  completeness,  accessibility,  and  timeliness  of  the  data  values.  High- 
quality  physical  data  is  useful  and  reliable  for  those  who  need  to  use  the 
information.  It  provides  information  that  carries  the  agreed  meaning,  in  a  format 
and  to  a  level  of  detail  that  meets  the  needs  of  the  wider  information-sharing 
community. 


Data  Quality 
Criticai  to 
Success  of 
CG 

information 

Architecture 


The  Coast  Guard  has  defined  its  open  systems  approach  in  COMDTINST 
M523QA5,  Information  Systems  Technology  Architecture.  This  Instruction 
identifies  data  as  one  of  four  critical  components  of  the  architecture.  The  data 
component  includes  information  classes,  ownership,  residence,  flow,  access,  and 
delivery.  Only  by  ensuring  high-quality  data  for  the  various  constituent  systems 
will  the  architecture  provide  tangible  benefit  to  mission-area  users. 


Standards  as 
a  Starting 
Point  for 
Other 
Functions 


By  incorporating  data  quality  and  security  dimensions  into  the  fleet  logistics  DA 
program,  the  CG  has  provided  the  Quality  Assurance,  System  Administration, 
and  Security  functions  with  a  reliable  starting  point. 

By  identifying  the  data  ownership,  access  control,  synchronization,  and 
validation  attributes  as  part  of  the  metadata,  the  ongoing  data  security  and 
integrity  functions  have,  for  each  application  system,  a  reliable  starting  point  for 
their  respective  responsibilities  that  require  decisions  about  data. 


Continued  on  next  page 


8-4 


Ensure  Data  Quality 


8.1.  Overview,  Continued 

ResponsI-  To  achieve  a  high  quality  central  information  resource,  participation  by  all  parts 
bllity  of  the  developer  and  mission  area  communities  is  critical.  The  following 

components  have  specific  responsibilities: 

•  Development.  Understand  the  implications  of  data  standards  to  system 
development.  Incorporate  these  requirements  into  the  analysis  and 
development  sequence.  Influence  design  decisions  in  favor  of  open,  not 
stovepipe,  systems.  Utilize  the  technical  support  and  data  encyclopedia 
resources  of  the  Data  Administration  office.  Translate  the  constructs  and 
terms  of  any  internal  methodologies  or  proprietary  CASE  tools  to  a  neutral 
format  for  delivery  as  reports  or  deliverables,  and  before  sharing  information 
with  other  teams.  The  system  architecture  and  database  design  teams  must 
take  the  lead  in  this  effort. 

•  Data  Administration:  Provide  rapid  response  time  and  sufficient  support  to 
facilitate,  not  inhibit,  system  development.  Provide  helpful  reviews  of 
submitted  metadata  and  design  documents.  Provide  clear  and  consistent 
dispositions  of  requests.  Ensure  compatibility  of  Coast  Guard  data  resources 
with  those  of  other  agencies  and  industry.  Update  and  distribute  standards 
information  in  a  timely  manner. 

•  Data  Stewardship:  Represent  the  assigned  functional  areas  in  a  complete 
and  professional  manner,  reflecting  applicable  standards,  requirements,  and 
best  practice.  Avoid  repeated  modifications  to  definitions  and  domains  by 
ensuring  the  initial  set  is  complete  and  authoritative.  Act  as  an  advocate  for 
the  users  of  the  assigned  categories  of  information.  Recruit  a  network  of 
functional  experts  to  advise  on  specific  issues.  Learn  data  administration 
concepts  and  data  modeling  skills,  to  quickly  assess  the  effects  of  proposed 
changes.  Provide  timely,  complete,  and  authoritative  response  to  requests. 

•  Information  System  DeveloperlUpgradelUser  team  Management:  Ensure 
that  all  design  reviews  and  submitted  documents  address  data  quality, 
security,  and  standards  issues.  Encourage  information  sharing  and  open 
systems.  Demonstrate  the  quality  advantages  and  cost  saving  opportunities 
of  central  information  resources.  Ensure  that  all  data  compatibility, 
standards,  security,  and  data  quality  issues  are  resolved  at  each  milestone. 
Design-in  quality  early  in  the  life  cycle,  to  avoid  subsequent  rework. 
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8.2.  Data  Quality  and  Security  Concepts 


Introduction  Reliability  and  quality  of  the  Coast  Guard  information  resource  depends  in  large 
part  upon  the  quality  and  consistency  of  the  underlying  metadata.  Protection  of 
the  Coast  Guard's  sensitive  information  depends  upon  clear  identification  of  data 
ownership  and  applicable  restrictions  to  access.  By  attention  to  these  principles, 
we  can  design-in  quality  and  dependability,  to  use  the  system's  information 
resources  for  the  intended  purposes. 

The  following  concepts  are  key  to  understanding  the  quality  and  security 
principles  that  are  implemented  in  this  section. 

Ensuring  Quality  of  data  values  is  attained  when  the  following  actions  are  performed  on  an 

Quality  of  information  system: 

Physical  Data  •  Identification  of  data  errors  and  faulty  processes 

•  Tracking  of  corrective  actions 

•  Improvement  of  business  processes  and  validation  rules 

•  Providing  an  automated  mechanism  for  restoration  of  data 

•  Training  the  creators  of  data  values  to  be  responsible  for  the  quality  of  the 
data  they  create. 

Data  quality  is  applied  to  the  aggregation  of  all  metadata  for  a  data  entity  or  data 
element.  As  the  metadata  is  refined  to  meet  the  exact  needs  of  the  user 
community,  the  quality  of  the  data  values  improves. 

Information  Building  an  information  system  that  functions  properly  and  is  used  to  its  full 
Management  potential  requires  detailed  planning.  Information  Management  Planning,  or 
Planning  Strategic  Data  Planning,  considers  the  organization's: 

•  Missions,  functions,  and  tasks 

•  Strategic  goals  and  objectives 

•  Priorities 

•  Subordinate  organizations 

The  quality  of  the  data  in  a  system  is  only  as  good  as  the  initial  information 
management  plan,  and  the  subsequent  execution  of  the  plan  through  modeling 
and  data  standardization.  Data  quality  concepts  should  be  built  into  this  process 
at  every  step.  COMDTINST  523 1 .2  requires  that  an  Automated  Information 
System  (AIS)  Proposal  be  submitted  to  G-TIS,  and  that  the  proposal  demonstrate 
valid  functional,  information  resources,  security,  and  support  planning.  A  fleet 
logistics  AIS  Proposal  should  include  in  its  Concept  of  Operation  the  intention  to 
participate  in  the  fleet  logistics  standard  data  resource,  and  in  its  System 
Resource  Requirements  the  need  for  the  applicable  network  interface  and  access. 

Continued  on  next  page 
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8.2.  Data  Quality  and  Security  Concepts,  continued 


Contingency  Contingency  plans  ensure  that  the  enterprise  data  resource  will  continue  to  be 
Planning  available  even  under  conditions  of  war,  natural  disaster,  power  failure,  fire,  or 

other  emergency.  Each  fleet  logistics  standard  information  system  must  have  a 
contingency  plan  similar  to  the  plan  described  in  COMDTINST  M5500.17 
Section  2.C.5.  The  plan  should  include  emergency  response,  backup  operations, 
disaster  assessment,  and  recovery  actions.  In  addition,  the  fleet  logistics 
metadata  repository  must  have  a  contingency  plan  because  the  data  dictionary 
provides  current  data  element  names,  attributes,  and  systems  where  used.  This 
information  is  used  to  prepare  ad-hoc  SQL  queries  and  reports,  and  is  mission- 
critical  to  the  users  of  the  information. 

Contingency  plans  that  provide  for  recovery  in  the  case  of  partial  or  full  system 
failure  should  be  built  into  the  system  from  the  very  onset  of  analysis  and  design. 
In  addition  to  hardware  recovery  procedures,  software  recovery  procedures  such 
as  backup  and  restore,  on-line  help,  and  field  service  must  be  considered. 
Periodic  data  quality  checks  should  include  the  evaluation  of  this  software, 
processing,  communication,  alternate  site,  and  administration  support. 

Likewise  the  fleet  logistics  DA  should  have  Continuity  of  Operations  plans  that 
are  built  into  all  of  the  data  integrity  and  quality  procedures  mentioned  in  this 
section. 


Standards  Information  system  standards  are  conditions  that  permit  sharing  of  information 
Compliance  between  unlike  systems  by  providing  definitions,  categories,  formats  and 
protocols  as  a  common  exchange  medium. 

Standards  compliance  is  necessary  for,  but  may  not  be  sufficient  for,  reliable 
information  sharing.  Standards  compliance  is  a  first  step  to  achieving  data 
quality.  The  standards  cited  and  incorporated  in  this  document  are  selected  to 
permit  data  sharing  with  CG,  DoD,  other  agencies,  and  private-sector 
organizations.  Standards  compliance  is  critical  to  efficient  accomplishment  of 
fleet  logistics  functions. 


Enterprise  The  fleet  logistics  enterprise's  total  data  resource  includes  all  of  the  data  that  it 
Data  creates,  collects,  stores,  maintains,  and  uses.  The  scope  and  definition  of  the 

Resource  enterprise  will  evolve  over  time.  The  scope  of  this  version  of  the  DAPAP 

manual  is  CG  fleet  logistics  organizations  and  the  systems  that  support  fleet 
logistics  work. 

Continued  on  next  page 
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8.2.  Data  Quality  and  Security  Concepts,  continued 


Data  Security  Data  security  protects  the  data  resource  from  unauthorized  access.  The  purpose 
of  this  protection  is  to  prevent  misuse  of  the  data  or  damage  to  it.  Security 
schemes  usually  protect  the  data  resource  from  both  malicious  and  inadvertent 
damage  and  misuse.  Data  security  provides  protection  for  data  that  must  be 
protected  due  to  legal,  regulatory,  or  operational  reasons.  A  data  security 
program  provides  access  to  identified,  authenticated  users  who  have  an  identified 
need.  While  security  administration  and  data  administration  are  separate 
functions,  data  ownership  and  level  of  protection  are  included  in  the  data  element 
naming  formula.  Providing  ownership  and  access  information  in  the  metadata 
ensures  consistent  access. 


Security  The  following  types  of  data  security  metadata  should  be  added  to  standard  data 

Metadata  entities  and  data  elements  to  ensure  consistent  protection.  Data  security  metadata 

addresses  the  user  access  restrictions  and  permissions  that  are  assigned  to  data 
entities  and  data  elements.  When  security  requirements  are  explicitly  bound  to 
an  entity,  applications  making  use  of  that  entity  will  have  the  necessary  security 
built  into  their  system  design.  The  different  types  of  security  metadata  that  can 
be  assigned  to  an  entity  include: 

•  Security  requirements  for  an  entity  name 

•  Security  requirements  for  entity  attributes 

•  Security  requirements  for  an  entity  in  relation  to  other  entities 

•  Security  requirements  for  some  or  all  values  of  specified  data  elements 


Data  integrity  Data  integrity  has  two  meanings:  integrity  of  data  values  and  integrity  of  design. 

Integrity  of  data  values  means  freedom  from  corruption,  loss,  or  other  threat  to  its 
accuracy.  Typical  precautions  to  verify  data  integrity  include  check  digits, 
counters,  and  comparisons.  System  administration  provides  data  integrity 
services  such  as  regular  backup  and  off-site  archiving.  Section  9  provides  for 
inclusion  of  indicators  and  formulas  in  metadata  for  verifying  data  integrity. 

Integrity  of  design  means  the  avoidance  of  redundancy,  clarity  of  entities  and 
attributes,  and  the  other  quality  criteria  provided  in  Section  8.6.  Flaws  in 
integrity  of  design  will  generate  corrupted  data  values.  For  data  elements  where 
data  integrity  depends  upon  business  rules,  the  mles  should  be  documented  as 
validation  formulas  in  the  data  element  definition.  These  formulas  and  indicators 
are  used  two  ways: 

•  Software  developers  use  the  integrity  formula  as  a  guide  to  provide  for 
consistent  checking  of  data  through  edit  checks  and  filters. 

•  Fleet  logistics  DA  and  data  stewards  use  these  formulas  and  indicators  along 
with  data  quality  audit  software  to  identify  data  quality  problems  in  the  shared 
data  resource. 


Continued  on  next  page 
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8.2.  Data  Quality  and  Security  Concepts,  Continued 


Data  In  a  functioning  system,  various  items  of  data  are  updated  at  different  times. 

Synchroniza-  Data  update  cycles  include  machine  cycle  times,  data  transfer  transactions, 

tion  system  run  cycles,  and  management  reporting  and  decision  cycles.  By 

identifying  and  documenting  update  cycles,  data  can  be  synchronized. 
Synchronization  indicators  in  a  data  element's  definition  permits  optimum 
programming  and  planning,  and  prevents  inadvertent  data  "clobbering"  and 
mismatching. 

The  open  systems  concept  is  a  design  goal  for  fleet  logistics  data  administration. 
In  an  open  system,  all  authorized  data  can  be  shared  transparently.  Transparent 
data  sharing  means  that  all  information  and  application  software  are  accessible 
(with  authorization)  from  any  standard  system  (that  is,  any  supported 
equipment/software  combination)  within  the  community.  Achieving  this  any-to- 
any  goal  of  enterprise-wide  transparent  data  sharing  requires  careful  observance 
of  design  principles  such  as  user  interface,  data  communication,  and  metadata 
standards. 


Legacy  This  term  implies  a  system  that  was  inherited,  meaning  that  its  creation  was 

Systems  outside  the  responsibility  of  the  current  program,  and  so  it  does  not  meet  current 

standards.  A  similar  term  used  in  DoD  is  "migration  system."  Legacy  systems 
support  functions  and/or  contain  data  that  is  of  interest  to  the  current  program, 
and  may  be  converted  to  become  compatible  with  the  current  system.  Upgrading 
of  a  legacy  system  or  migrating  its  data  requires  redefinition  of  its  data  structures 
and  data  element  definitions  in  terms  of  the  current  standards. 


What  is  a  A  CG  fleet  logistics  standard  system  is  an  information  system  in  which  the  data 

Standard  interfaces,  data  structure,  and  application  software  are  accepted  as  compliant 

System?  with  the  related  standards.  Standard  systems  are  registered,  and  are  enabled  to 

share  data  with  the  other  fleet  logistics  standard  systems.  This  registration 
indicates  that  the  system's  shareable  data  is  consistent  with  standard  metadata, 
and  will  not  corrupt  other  standard  systems'  data  when  data  values  are  combined 
or  summarized. 

The  effectiveness  of  this  data  quality  and  security  effort  within  data 
administration  will  directly  affect  the  reliability  and  usefulness  of  the 
information  resource  that  is  built  and  shared  by  these  standard  systems. 

Standards  A  new  system  will  be  registered  as  a  standard  fleet  logistics  information  system 

Compliance  when  the  system's  developers  have  demonstrated  adherence  to  the  process 

models,  data  models,  and  data  standardization  procedures  of  the  DAPAP  manual. 


Open 

(Standard) 

Systems 
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8.3.  Ensuring  Compliance  with  Data  Standards 


Purpose  The  first  level  of  data  quality  is  compliance  with  data  standards.  The  compliance 

and  enforcement  tasks  that  are  described  in  this  subsection  provide  information, 
support,  and  incentives  to  the  developer  and  program  manager  teams  who  create 
and  maintain  information  systems. 

The  specific  standards  for  data  models,  data  entities,  and  definitions  are 
described  in  the  previous  subsections.  This  subsection  reviews  the  overall 
process  for  facilitating  developer  compliance. 

The  main  point  of  the  standards  compliance  effort  is  to  ensure  that: 

•  Data  processes,  models,  entities,  elements,  and  definitions  are  described 
sufficiently  to  support  enterprise-wide  data  sharing,  and 

•  In  each  development  task,  data  definition  and  naming  decisions  are  made 
by  selecting  a  close  match  from  the  menu  of  available  standard  definitions 
first,  and  only  creating  new  or  revised  metadata  in  cases  where  no  standard 
definition  can  be  applied. 


Means  to 

Ensure 

Compliance 


Data  standards  compliance  is  achieved  through  cooperation  of  the  CG  fleet 
logistics  enterprise  community  by  perception  of  the  value  of  high-quality, 
sharable  data.  This  understanding  and  appreciation  of  the  value  of  the  enterprise 
information  resource  can  be  achieved  by  the  following  means: 


1.  Education  and  outreach  to  information  system  developier  and  program 
management  personnel 

2.  Facilitation  and  technical  support  of  analysts  and  designers 

3.  Review,  with  constructive  comments  and  discrepancy  resolution,  of  online 
models  and  deliverable  documents 

4.  Acceptance  and  registration  of  systems  that  meet  the  standards 

5.  Providing  reliable  and  responsive  data  sharing  support  to  users  of  registered 
systems 

6.  Controlling  and  validating  requests  for  new  metadata,  changes  to  standard 
metadata,  and  exemption  from  standards 


Continued  on  next  page 
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8.3.  Ensuring  Compliance  with  Data  Standards,  Continued 


Applicability  The  standards  and  processes  described  in  this  document  apply  to  any  new  CG 

fleet  logistics  information  system  or  process  that: 

1 .  Creates,  updates,  or  uses  data  that  crosses  organization  boundaries. 

2.  Uses  data  from  and/or  should  contribute  data  to  the  fleet  logistics  DA 
standard  data  resource. 

And  to  existing  information  systems  that: 

1 .  Are  being  upgraded,  with  the  upgrade  anticipated  to  affect  30%  or  more  of 
the  existing  lines  of  code,  or  which  adds  functions  or  interfaces  (not  just  a 
maintenance  release) 

2.  Add  any  new  data  entity  definitions,  or  modify  standard  data  entity 
definitions  by  adding  or  modifying  data  element  (entity  attribute) 
definitions. 

3.  Use  data  from  or  should  contribute  data  to  the  fleet  logistics  DA  standard 
data  resource. 
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8.4.  DA  Education  and  Outreach 


Purpose  The  goal  of  the  education  and  outreach  effort  is  to  minimize  the  amount  of 

rework  required  after  submittal  of  data  models  and  data  element  definitions.  The 
role  of  this  proactive  fleet  logistics  DA  coordination  and  guidance  task  is  to 
allow  system  designers  the  room  to  think  creatively,  and  then  to  identify  the  best 
match  to  standard  processes,  data  models,  entities,  elements,  and  definitions. 

This  metadata  support  permits  designers  to  achieve  metadata  consistency  and  full 
use  of  the  standard  data  resource  before  submittal. 

Data  standards  compliance  is  the  responsibility  of  each  program  manager  and 
developer.  Fleet  logistics  DA  will  train  and  facilitate  developer  teams  to  ensure 
success  and  to  save  redesign  time.  This  education  and  facilitation  role  will  be 
performed  for  systems  that  have  been  authorized  for  design,  but  have  not  yet 
submitted  Database  Definition  Documents.  It  does  not  replace  the  developer's 
responsibility  to  meet  the  standard,  but  intends  to  show  how  to  meet  the  standard 
in  a  complete  and  useful  manner. 


Provide  In  the  general  role  of  data  standards  outreach,  the  individual(s)  tasked  with 

Training  and  coordination  should  perform  the  following  general  duties: 

Facilitation 

1 .  For  each  program  management  and  development  team,  ensure  that  all  team 
members  are  trained  in  the  provisions  of  fleet  logistics  DA  standards,  use  of 
the  fleet  logistics  DA  repository,  and  in  the  processes  described  in  this 
document.  (Training  in  specific  methodologies  and  tools  is  the  responsibility 
of  the  developer.) 

2.  Ensure  that  each  program  management  and  development  team  is  aware  of  the 
metadata  deliverables  that  are  due  with  each  milestone  in  the  development 
life  cycle. 

3.  Facilitate  authorization  of  access  for  development  team  members  to  the  fleet 
logistics  DA  data  encyclopedia. 

4.  Brief  program  management  and  development  teams  as  needed  regarding 
choice  of  metadata  analysis  and  management  tools,  methods  used  by 
previously  successful  development  teams,  and  evaluation  criteria  for 
deliverables. 


Continued  on  next  page 
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8.4.  DA  Education  and  Outreach,  Continued 


Provide  Initial  This  proactive  outreach  role  provides  the  development  team  (or  data  steward  or 
Guidance  data  users)  with  data  compatibility  goals,  sets  achievable  expectations,  and  shows 

the  team  how  to  use  the  standard  data  tools  to  speed  up  development.  The  DA 
representative  will  provide  information  as  training  or  a  series  of  briefings  to  the 
program  management  and  development  teams  for  each  application. 

These  briefings  will  cover  the  following  topics: 

•  Goals  of  the  data  administration  program 

•  Data  administration  process  and  functions 

•  Fleet  logistics  conceptual  data  architecture 

•  Process  and  data  modeling 

•  Metadata  life  cycle  as  part  of  the  system  life  cycle 

•  Data  administration  components  of  requirements  and  design  documents 

•  Developer's  responsibilities  to  achieve  standard  data 

•  Use  of  CASE  tools  to  prepare  submittals 

•  How  to  prepare  and  submit  data  models 

•  Standard  forms  and  examples  for  data  models 

•  How  to  prepare  and  submit  standard  data  element  requests 

•  Standard  forms  and  examples  for  data  elements 

•  How  to  request  information  and  obtain  technical  support 

•  Standard  system  registration:  user  benefits  and  program  implications 

A  standard  set  of  briefing  materials  will  be  provided.  The  DA  representative  can 
supplement  these  materials  with  program-specific  examples  and  material  from 
the  representative's  professional  experience. 
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8.5.  Facilitation  and  Technical  Support 


Purpose  This  subsection  describes  the  facilitation  and  technical  support  activities,  by 

which  fleet  logistics  DA  can  encourage  participation  in  the  data  standards 
program  and  can  save  review  and  rework  time. 


Facilitation  Facilitation  involves  the  following  tasks; 

1 .  Review  preliminary  design  documents  to  identify  as  early  as  possible  the 
opportunities  for  data  commonalty  and  risks  to  data  security  and  integrity. 

2.  Review  data  flow  descriptions  to  identify  enterprise-wide  implications  for 
data  interface,  integrity,  security  and  synchronization. 

3.  Review  preliminary  system  and  interface  requirements  documents.  From  this 
review,  identify  the  intended  uses  for  the  data,  and  apply  this  insight  to 
ensure  accurate  selection  of  standard  metadata  and  appropriate  submittal  of 
requests  for  new  or  revised  metadata  items. 

4.  Improve  the  integrity  and  usage  of  data  through  principles  and  standards,  and 
by  coordinating  data  element  definitions  among  functional  and  line 
organizations. 

5.  Inform  fleet  logistics  DA  of  the  status  of  the  project's  metadata  deliverables, 
potential  delays,  and  opportunities  to  improve  the  process  or  facilitate  a 
problem. 


Verify  Fleet  logistics  DA  provides  technical  support  to  identify  and  anticipate  the 

Opportunities  potential  opportunities  for  common  definitions  among  developing  systems,  to  use 
for  Metadata  existing  sharable  data,  and  to  define  consistent  interfaces.  For  each  opportunity: 

Commonalty 

1 .  Identify  the  appropriate  information  class,  and  include  the  relevant  data 
steward  in  the  definition  process. 

2.  Identify  other  agencies  with  whom  the  application's  data  might  be  shared, 
and  ensure  that  the  definition  is  compatible  with  the  format  and  definition 
of  the  corresponding  entity  in  the  other  system(s). 

3.  Review  the  definitions  of  related  data  entities  and  elements,  to  ensure  that 
the  level  of  detail  is  consistent. 


Coordination  Fleet  logistics  DA  coordinates  this  process,  relying  on  data  stewards  to  make 
Responsibility  these  determinations  for  the  appropriate  information  classes. 
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8.5.  Facilitation  and  Technical  Support,  continued 


Tools  and  Fleet  logistics  DA  provides  technical  support  for  recommended  process 
Repository  modeling,  data  modeling  and  other  CASE  tools.  This  support  focuses  on  loading 
Support  standard  metadata  into  the  tool,  identifying  standard  entities  and  elements  that 

meet  application  data  requirements,  and  preparing  metadata  deliverables  for 
review.  Fleet  logistics  DA  as  operator  of  the  data  encyclopedia,  answers 
questions  and  solves  problems  regarding  user  access,  report  generation,  and 
available  information. 
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8.6.  Metadata  Review  Processes  and  Criteria 


Purpose  Review  of  models  and  deliverable  documents  is  the  main  fleet  logistics  DA 

compliance  activity.  This  subsection  shows  the  review  and  control  points  in  a 
system  development  life  cycle. 

This  subsection  includes  quality  checklists  for  process  models,  data  models,  and 
data  elements.  If  these  criteria  are  used  to  prepare  and  evaluate  definitions,  both 
the  developer  and  the  administrator  will  save  time,  and  the  resulting  data  will  be 
more  portable,  complete,  high-quality,  and  sharable. 

Metadata  The  review  and  acceptance  procedures  in  Section  3,  Develop  and  Integrate 

Review  Data  Models,  and  Section  4,  Standardize  Data  Elements,  include  the  specific 

data  quality  and  security  check  points  that  implement  the  guidelines  described 
here.  Quality  and  security  reviews  shall  be  part  of  the  review  of  each  submitted 
data  model. 

In  addition,  each  candidate  data  entity  and  element  definition  and  change  request 
shall  be  reviewed  to  conform  to  the  data  security  and  integrity  requirements 
described  in  this  section. 

General  The  review  and  acceptance  procedures  for  data  models  and  data  elements  include 

Review  review  points  that  answer  the  following  questions: 

Guidelines 

1 .  Is  each  data  entity  (in  a  model)  or  data  element  (in  a  DBDD)  defined  in 
sufficient  detail  to  evaluate  its  definition  and  attributes? 

2.  Is  each  data  entity  or  data  element  defined  sufficiently  to  determine  its 
uniqueness,  and  to  identify  its  use  in  the  system-wide  data  resource? 

3.  Is  the  definition  and  attribute  set  consistent  with  that  of  related  items? 

4.  Is  the  ownership  (creation  and  update  responsibility)  of  the  data  identified? 

5.  Is  any  restricted  access  requirement  identified,  and  need-to-know  criteria 
established? 

6.  Is  the  relationship  of  this  data  element  to  other  data  (link,  update,  superset) 
indicated  in  the  definition?  (relationship  implied  in  the  model  but  must  be 
explicit  in  the  DE  definition) 

7.  If  the  data  element  is  updated  periodically,  are  the  source  of  the  update,  the 
application  performing  the  update,  and  the  update  schedule/cycle  indicated? 

8.  If  the  data  can  be  checked  for  external  validity,  is  the  algorithm  for  the 
recommended  validity  check  supplied? 

Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Metadata  Quality  and  security  issues  are  integrated  throughout  the  functions  and 

Review  by  procedures  described  in  this  manual.  The  following  table  summarizes  the 

Develop-  metadata  to  be  submitted  and  evaluated  at  each  development  milestone,  to  ensure 
merit  Phase  that  data  quality  and  security  have  been  designed-in. 


Data  Quality  Review  Points  by  System  Development  Phase 


Development 

Phase 

Process  Model: 

Data  Model 

Data  Element 
Definitions 

Plaiming 

Mission  need, 
conceptual 
architecture,  and 
prototypes 
evaluated 

Potential  for  use  of 
shared  data;  risk 
analysis 

Requirements 

Analysis 

Review  Functional 
Description  or  System 
Spec,  and  preliminary 
process  model 

Analyze  risk  and 
potential  synch, 
problems;  review 
logical  data  model 

System 

Design 

Review  revised 
process  model, 
including  process 
cycle  time  estimates. 

Review  prelim,  attr. 
data  model. 

Reconcile  data  model 
to  process  model. 
Review  preliminary 
DBDD 

Ensure  quality  and 
security  attributes  are 
part  of  DE  definitions. 
Review  requests  for 
changes  and  for  new 
data  elements  where 
needed. 

Detailed 

Design 

Review  fully 
attributed  data  model 
and  DBDD  Version  1 
(baseline).  Resolve 
discrepancies. 

Resolve  all  change 
requests  and  standards 
discrepancies. 

Development 

Review  any 
technology-driven  or 
requirements-driven 
changes 

Review  any 
technology-driven  or 
requirements-driven 
changes 

Integration 
and  Testing 

Identify  and 
resolve  integration 
issues. 

Identify  and 
resolve  integration 
issues. 

Demonstrate  data 
portability, 
compatibility,  and 
quality. 

Identify  and 
resolve  integration 
issues. 

Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 

Metadata  Review  by  Development  Phase  Continued 


Development 

Phase 

Process  Model; 

Data  Model 

Data  Element 
Definitions 

Acceptance 

As-built  data  model 
accepted.  Review 
Product  Baseline 
(Version  3)  DBDD. 

All  data  items 
approved  or  waivered. 
System  registered  for 
data  sharing. 

Operations 

Revise  process 
model  to  describe 
current  practice. 

Update  metadata 
to  support  changes 
in  requirements. 

Verify  data  values 
are  consistent  with 
metadata 

Retirement 

Ensure  smooth 
transition  of 
processes 

Ensure  smooth 
transition  of  data 

Ensure  smooth 
transition  of  data 

Continued  on  next  page 


Ensure  Data  Quality 


8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Standardiza-  Upgrading  and  standardization  of  an  application's  data  structures  requires 

tion  Process  delineation  and  coordination  of  tasks  by  the  fleet  logistics  DA  Office,  the 

Responsi-  application  owner/developer  and  data  stewardship  teams.  The  following  tables 

bilities  identifies  the  tasks  with  the  responsible  party. 


Responsibility 

Tasks 

Fleet  logistics  DA 
Office 

Identifies  a  system's  place  in  the  enterprise  data  model. 

Fleet  logistics  DA 
Office 

Determines  the  need  for  a  system's  data  to  be  standardized 

Fleet  logistics  DA 
Office 

Supports  and  facilitates  the  data  standardization  process. 

Fleet  logistics  DA 
Office;  data 
stewards 

Assesses  the  effect  (cost,  function,  time)  on  the  application 
area  and  on  the  fleet  logistics  DA  community  of 
standardizing  and  of  remaining  nonstandard. 

Fleet  logistics  DA 
Office 

Determines  whether/ when  system  must  be  upgraded  to  meet 
fleet  logistics  DA  standards. 

Developer 

Examines  current  data  structure  and  definitions. 

User 

Describes  and  assesses  the  current  quality  of  the  interfaces 
between  the  application  and  other  systems. 

User  and 

Developer 

Assesses  and  models  the  business  processes  within  the 
scope  of  the  application. 

Developer 

Assesses  and  redefines  all  data  entities,  applying  standard 
entity  definitions  wherever  possible. 

Developer 

Identifies  remaining  entities  as  potential  unique  entities 
and  prepares  requests  for: 

•  New  standard  definitions 

•  Modification  or  extension  of  a  definition 

•  Waiver  for  internal  non-sharable  entities 

Developer 

Defines  process  model,  data  model,  entities,  and  data 
elements  in  accordance  with  fleet  logistics  DA  standards. 

Developer 

Submits  proposed  attributed  data  model  as  part  of  DBDD 
for  Design  milestone. 

Developer 

Develops  physical  design  in  accordance  with  approved 
data  model. 

Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Standardiza-tion  Process  Responsi-bilities  (continued) 


Responsibility 

Tasks 

Developer 

Develop  and  test  the  system,  using  the  approved  data 
structures  only. 

Developer 

At  physical  configuration  audit,  demonstrate  standard, 
sharable  data  and  receive  registration. 

Database 

administrator 

Provide  data  configuration  control 

Data  Stewards 

Determine  where  data  is  used  throughout  the  CG  as  it 
relates  to  the  assigned  information  classes  and 
functional  areas. 

Data  Stewards 

Determine  impact  of  change  on  other  current  and  planned 
systems  (where-used  report) 

Data  Stewards, 
subject  matter 
experts 

From  knowledge  of  the  function,  establish  recommended 
processes  and  data  definitions. 

Data  Stewards, 
subject  matter 
experts 

Determine  functional  merit  of  change  requests  to  standard 
definitions. 

Data  Stewards, 
subject  matter 
experts 

Determine  functional  merit  (uniqueness,  usefulness)  of 
proposals  for  new  data  entity  and  element  definitions. 

Review  of 
Activity 
(Process) 
Models 


A  business  process  or  activity  model  represents  the  relationship  of  the  business 
processes  in  the  enterprise.  The  data  administrator's  interest  in  a  process  model 
is  based  upon  the  process  model's  context  for  the  data.  Process  models  should 
contain  sufficient  detail  to  derive  a  data  model,  and  to  support  the  definition  of 
each  data  entity.  So,  from  a  data  standards  point  of  view,  a  process  model  is 
acceptable  if  it  contains  adequate  information  to  derive  the  data  model  and  to 
initiate  the  definition  of  all  data  entities.  Likewise,  when  a  data  administrator 
reviews  a  data  model,  all  data  entities  should  be  traceable  to  the  process  model. 

Data  administrators  should  begin  to  understand  the  application  by  reviewing  the 
process  model  for  outside  interfaces,  identification  of  previously  defined 
processes,  risk  analysis,  data  security  and  integrity  issues,  and  data 
synchronization.  Resolution  of  these  issues  should  precede  approval  of  the 
application-level  process  model. 


Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 

Review  of  This  checklist  shall  be  used  by  developers  as  they  prepare  candidate  data  entity 

Data  Models  definitions  (new  or  modifications  of  standard  entities)  and  by  fleet  logistics  DA 

staff  to  review  data  entity  requests  using  the  procedures  in  Section  3,  Data 
Models.  As  quality  standards,  these  criteria  describe  the  level  of  consistency  and 
completeness  to  build  an  enterprise-wide  data  model,  and  to  provide  a  useful 
basis  for  evaluating  and  defining  data  elements.  If  these  criteria  are  used  to 
prepare  and  evaluate  definitions,  both  the  developer  and  the  administrator  will 
save  time,  and  the  resulting  data  will  be  more  portable,  complete,  high-quality, 
and  sharable. 

To  be  a  candidate  for  integration  into  the  enterprise  data  model,  a  submitted  data 
model  should  meet  the  following  requirements: 


Quality 

Principle 

Criterion 

Relationship  to  the 
Real  World 

Relevance 

The  view  should  provide  data  needed 
by  the  application,  by  other  fleet 
logistics  applications,  and  to  facilitate 
data  sharing  with  allied  agencies. 

Obtainability 

Data  values  should  be  easily 
obtainable,  as  identified  in  each  data 
entity  definition. 

Clarity  of  definition 

Each  item  in  the  definition  of  the  view 
should  be  clearly  defined. 

Comprehensiveness 

Each  needed  data  item  should  be 
included. 

Necessity 

No  unneeded  data  items  should  be 
included. 

Naturalness 

Each  item  in  the  view  should  have  a 
"natural"  counterpart  in  the  real  world. 

Occurrence 

identifiability 

The  view  should  make  identification 
of  individual  entities  easy. 

Systemic  consistency 

The  view  should  be  clear  and 
unambiguous  and  consistent. 

Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Review  of  Data  Models  (continued) 


Quality 

Principle 

Criterion 

Level  of  Detail 

Precision  of  Domains 

The  domains  of  possible  values  should 
be  large  enough  to  support  anticipated 
applications,  and  to  support  data 
sharing  with  allied  agencies. 

Attribute  details 

The  attributes  should  be  defined  at  a 
sufficient  level  of  detail  to  support 
applications,  queries,  and  data  sharing. 

Robustness  of  View 

The  view  should  be  wide  enough  so 
that  it  does  not  require  change  every 
time  applications  change. 

Consistency  of 
Definition 

Homogeneity 

Entity  types  should  be  defined  to 
minimize  the  occurrence  of 
unnecessary  attributes. 

Minimum  redundancy 

Redundancy  of  occurrences  of  data 
elements  should  be  kept  to  a 
minimum.  Each  redundant  entry  must 
be  justified. 

Entity  types  and  attributes  should  have 
the  same  basic  structure  wherever 
possible. 

Content 

Definitions  must  indicate  entity 
ownership,  any  access  restriction, 
s5mchronization  requirements,  and 
validation  algorithm  as  appropriate. 

Flexibility 

Definitions  must  include  the  same 
kinds  of  attributes  sufficiently  to 
permit  all  anticipated  application  and 
enterprise  views  without  additional 
analysis. 

After  T.C.  Redman,  Data  Quality:  Management  and  Technology,  1993 
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8.6.  Metadata  Review  Processes  and  Criteria,  Continued 


Common 

Consistency 

Problems 


The  three  most  common  problems  in  defining  data  entities  and  elements  are: 

1 .  Same  (or  functionally  similar)  definitions  corresponding  to  multiple  data 
entities  or  elements  (synonyms). 

2.  Same  (or  substantially  the  same)  data  entity  or  element  name  with  multiple 
definitions  (homonyms) 

3.  Apparently  the  same  data  elements  with  multiple  formats  or  characteristics. 

4.  By  selecting  first  from  existing  definitions  and  then  submitting  the 
remaining  unique  items,  the  information  systems  analyst  can  reduce 
definition  time,  increase  data  compatibility,  and  ensure  approval. 


Data  Element 

Quality 

Checklist 


The  following  four  checklists  provide  criteria  for  use  in  the  Section  4, 
Standardize  Data  Elements  acceptance  procedures.  As  quality  standards,  these 
criteria  describe  the  level  of  consistency  and  completeness  needed  to  build  a 
useful  resource  of  enterprise-wide  data  element  definitions. 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Data  Element  Relevance  ensures  that  each  data  element  is  associated  with  the  appropriate 
Quality:  standard  entity,  and  that  the  definition  provides  useful  information. 

Relevance 


Quality 

Principle 

Criterion 

Relevance 

Traceability  in 
Application 

Represents  a  characteristic  (attribute) 
of  one  and  only  one  data  entity  in  the 
previously  accepted  data  model. 
Provides  a  logical  basis  for  and  lends 
integrity  to  DE  definitions. 

Relation  to  Standard 

Definition  provides  a  useful  and 
necessary  addition  to  the  set  of  similar 
standard  data  elements.  Element  is 
defined  consistently  in  level  of  detail 
and  attributes  compared  to  similar 
standard  elements. 

Merit 

Has  demonstrable  merit  as  a  data 
element,  serving  an  identifiable 
purpose. 

Naming 

The  data  element  name  starts  with  the 
name  of  the  entity  of  which  it  is  an 
attribute,  and  contains  sufficient 
modifiers  to  show  its  purpose  and 
uniqueness. 

Continued  on  next  page 


8-24 


Ensure  Data  Quality 


8.6.  Metadata  Review  Processes  and  Criteria,  Continued 

Data  Element  The  "scope"  criteria  ensure  that  the  data  element  precisely  describes  the 
Quality:  information  intended,  and  only  that  information. 

Scope  and 
Definition 


Quality 

Principle 

Criterion 

Scope 

Conciseness, 

precision 

Has  a  single  purpose  and  a  single 
meaning  (concept). 

Uniqueness 

Avoids  overlap  or  redundancy 

Clarity 

Ensures  common  understanding  by 
clearly  indicating  what  the  data 
element  represents. 

Atomic 

A  basic  unit  of  information;  cannot  be 
subdivided  without  losing  its  meaning 
or  creating  redundant  elements. 

Definition 

Function 

Defined  according  to  functional 
requirements  and  not  physical 
characteristics,  (i.e.,  no  connotations 
of  physical  location,  organization,  or 
application) 

Exception:  data  'ownership'  and 
restricted  access  attributes. 

Purpose 

Defined  according  to  the  purpose  of 
the  data  element,  not  how,  where,  or 
when  the  DE  is  used  or  who  uses  it. 

Continued  on  next  page 
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8.6.  Metadata  Review  Processes  and  Criteria,  Continued 

Data  Element  The  format  of  the  data  element  definition  determines  its  consistency  with  other 

Quality:  definitions,  and  therefore  affects  its  usefulness  and  clarity. 

Format  and 
Attributes 


Quality 

Principle 

Criterion 

Format  and 
Attributes 

Format  Compliance 

Utilizes  the  standard  data  element 
definition,  format,  and  notation 
specified  in  Section  4. 

Generic  or  Reference 
Element  Utilization 

Based  upon  the  appropriate  generic 
element  or  reference  element  in 
structure  and  physical  characteristics. 

Attribute  Consistency 

Similar  data  elements  are  defined  to 
the  same  level  of  detail  regarding  data 
types,  domain,  and  definition. 

Standards 
Compliance 
for  Existing 
Systems 


A  fleet  logistics  information  system  must  be  upgraded  to  be  acceptable  for 
standard  system  registration  if  it  also  requires  AIS  Proposal  approval  by 
Commandant  (G-TIS)  as  described  in  COMDTINST  5231.2.  This  requirement 
includes  criteria  of  where  the  system’s  information  originates,  use  of  the  system 
in  more  than  one  CG  district,  and  acquisition  cost. 


Systems  that  were  authorized  for  development  before  December  31,  1994  will  be 
considered  as  "current  fleet  logistics  information  systems,"  and  will  not  be 
required  to  comply  with  these  data  standards  unless  and  until  one  or  more  of  the 
conditions  listed  in  COMDTINST  5231.2  becomes  true,  or  unless  the  system 
requires  sharing  of  data  with  other  fleet  logistics  information  systems. 
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8.6.  Metadata  Review  Processes  and  Criteria,  continued 


Metadata  During  review  of  plans,  requirements  and  design  documents,  data  models  and  data 

Deficiency  elements,  fleet  logistics  DA  will  first  advise  the  developer  of  discrepancies 

Tracking  and  informally  and  request  correction  and  re-submittal.  For  discrepancies  that  are  too 
Correction  large  for  informal  request  and/or  when  full  corrective  response  does  not  occur 
promptly,  fleet  logistics  DA  staff  will  implement  the  following  corrective  action 
process: 

•  Note  each  problem  or  discrepancy  on  a  Metadata  Discrepancy  Report  (provided 
in  Appendix  D).  Identify  each  discrepancy  on  a  separate  form.  Link  the  report 
to  the  subject  request  by  citing  the  tracking  number  that  DA  assigned  when  the 
metadata  request  was  submitted. 

•  Classify  each  discrepancy  by  priority  and  category,  and  record  the  desired 
disposition  and  suspense  date. 

•  Developer  and  fleet  logistics  DA  office  will  keep  a  discrepancy  list  with  the 
current  status  of  each  item.  In  case  of  a  conflict,  the  fleet  logistics  DA  version 
of  the  list  prevails. 

•  Correspondence  and  submittals  should  cite  the  Discrepancy  Report  tracking 
number. 

•  Developer  corrects  deficiencies  item-by-item,  and  reports/submits  correction  to 
fleet  logistics  DA  office. 

•  A  repeat  of  the  standards  and  stewardship  review  cycle  will  be  conducted 
when  all  discrepancy  items  have  been  resolved,  to  determine  whether 
additional  problems  have  been  introduced,  and  whether  correction  has 
revealed  additional  problems,  discrepancies,  and/or  open  issues. 

Deficiencies  will  be  corrected  against  the  version  of  the  metadata  or  change 
request  that  was  submitted  to  DA.  After  resolution  of  discrepancies,  DA  will 
approve  the  corrected  version  of  the  metadata  (hardcopy  or  model)  or  change 
request,  and  will  then  transmit  it  to  CM  for  release. 

Corrective  actions  will  be  evaluated  to  verify  that  problems  have  been  resolved, 
adverse  trends  have  been  reversed,  and  changes  have  been  correctly  implemented 
in  the  appropriate  metadata. 


Ensure  Data  Quality 


8.7.  Acceptance  and  Registration  of  Standard  Systems 


Purpose  The  goal  of  the  compliance  effort  and  the  incentive  for  a  system's  developer  is  to 

achieve  data  standards  acceptance,  and  to  have  the  system  registered  as  a  fleet 

logistics  DA  standard  system.  The  incentive  for  registration  is  enterprise-wide 

data  sharing. 

Fleet  To  ensure  the  best  quality  and  availability  of  shareable  information  between 

Logistics  DA  Coast  Guard  information  systems,  the  fleet  logistics  DA  office  must  execute  the 
Responsi-  following  responsibilities: 

bilities 

1 .  Review  all  models  and  data  elements  submitted  by  the  software 
development  teams  for  standards  compliance,  and  recommend 
modifications 

2.  Assign  each  metadata  request  (add,  change,  exemption)  to  the  appropriate 
Data  Steward,  and  ensure  appropriate  functional  expert  review  of 
deliverable  documents. 

3.  Negotiate  and  resolve  any  disagreements  between  the  software 
development  team,  the  Data  Steward,  and  other  related  stakeholders,  as 
required 

4.  Determine  the  enterprise-wide  impact  of  the  new  system  and  its  data 
elements 

Data  To  ensure  that  the  metadata  for  an  information  class  matches  the  available 

Stewardship  standards  and  meets  the  needs  of  the  user  community,  each  data  stewardship 
Responsibili-  team  must  execute  the  following  responsibilities: 

ties 

1 .  Identify  and  select  functional  expert(s)  to  the  software  development/review 
team  for  a  new  system 

2.  Assign  functional  expert(s)  for  the  review  of  models  and  data  elements 

3.  Negotiate  disagreements  between  functional  experts  and  software 
developers,  as  necessary 

4.  Provide  the  fleet  logistics  DA  with  models  and  data  elements  approved  by 
the  Data  Steward 
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8.7. 


Acceptance  and  Registration  of  Standard  Systems, 


Continued 


Developer  To  ensure  that  the  system  under  development  provides  and  uses  standard  data,  and 
Responsibiii-  to  avoid  the  costs  of  developing  and  maintaining  unique,  incompatible  systems, 
ties  each  software  development  team  that  is  authorized  beyond  the  proof-of-concept 

(prototype)  stage  shall: 

1 .  Develop  data  elements  and/or  data  models  according  to  fleet  logistics  DA 
guidelines 

2.  Submit  data  models  and/or  data  elements  to  DA  for  approval 

3.  Abide  by  all  decisions  of  the  fleet  logistics  DA,  and  implement  changes  as 
required  on  the  new  system 


Acceptance  of  Acceptance  of  a  DA  standards  compliant  new  system  includes  the  following 
a  Standard  steps,  conducted  by  fleet  logistics  DA: 

New  System 


Step 

Action 

1 

Review  final  DBDD  and  IDD(s)  for  conformance  to  data  standards  and 
for  traceability  from  the  approved  data  model  to  requirements  to  physical 
database  and  interface  design. 

2 

Confirm  that  all  Discrepancy  Reports  have  been  resolved. 

3 

Perform  a  Physical  Configuration  Audit  of  data  structures, 
implementation  of  business  rules,  validation  of  data  values,  and 
definitions. 

4 

Demonstrate  data  portability:  export  of  the  candidate  system's  data  to 
another  standard  system.  Evaluate  use  without  generating  errors. 

5 

Test  the  system  across  the  Coast  Guard  Wide  Area  Network,  using 
standard  SQL  requests.  Evaluate  the  response  for  completeness  and 
accuracy.  Likewise,  from  the  candidate  system  generate  requests  that 
merge  standard  resource  data  with  the  system's  data  and  evaluate  the 
result. 

6 

Reconcile  the  candidate  data  model  into  the  fleet  logistics  DA  enterprise 
data  model  as  described  in  Section  3;  “Support  Integration  of  Data,” 
and  “Incorporate  Data  Model  Into  Repository.” 
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8.7.  Acceptance  and  Registration  of  Standard  Systems, 

Continued 


Acceptance  of  Acceptance  of  a  DA  standards  compliant  upgraded  system  includes  the  following 
a  Standard  steps,  conducted  by  fleet  logistics  DA: 

Upgraded 

System 


Step 

Action 

1 

Review  final  DBDD  for  conformance  to  data  standards  and  for 
traceability  from  physical  design  to  data  model  to  process  model  to 
requirements. 

2 

Confirm  that  all  Discrepancy  Reports  have  been  resolved. 

3 

Perform  a  Physical  Configuration  Audit  of  data  structure,  process,  and 
definitions. 

4 

Demonstrate  of  data  portability:  export  of  the  candidate  system's  data  to 
another  standard  system.  Evaluate  use  without  generating  errors. 

5 

Test  the  system  across  the  Coast  Guard  Wide  Area  Network,  using 
standard  SQL  requests.  Evaluate  the  response  for  completeness  and 
accuracy.  Likewise,  from  the  candidate  system  generate  requests  that 
merge  standard  resource  data  with  the  system's  data  and  evaluate  the 
result. 

6 

Incorporate  the  candidate  data  model  into  the  fleet  logistics  DA 
enterprise  data  model. 
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8.7.  Acceptance  and  Registration  of  Standard  Systems, 

Continued 


Registration  Registering  a  new  or  upgraded  system  as  a  fleet  logistics  Standard  System  is  the 
Process  final  step  in  bringing  a  new  or  upgraded  information  system  into  the  fleet 

logistics  enterprise.  Registration  indicates  that  the  system’s  data  is  transparently 
shareable  across  the  enterprise,  and  the  system’s  data  quality  can  be  trusted.  This 
process  starts  with  review  of  the  Data  Conversion  Plan  (described  in  Section  5). 

The  registration  process  includes  the  following  steps: 


Step 

Action 

1 

Provide  a  letter  to  the  program  manager  indicating  the  system’s 
acceptance  and  registration. 

2 

Add  to  the  repository  the  new  standard  system’s  name  so  that  the  new 
system  is  included  in  all  relative  metadata  calls  to  it  throughout  the  fleet 
logistics  data  model  and  the  data  dictionary. 

3 

Add  to  the  repository  the  new  standard  system’s  name  to  the  data 
elements  whose  values  are  created,  modified  or  used  by  the  system,  so 
that  the  system  is  included  in  impact  analysis  (where-used)  reports. 

4 

Add  to  the  distribution  list  for  fleet  logistics  DA  data  standards  and 
resource  information. 

5 

Notify  network  administrators  to  add  the  new  system  to  their  lists  of 
“trusted  systems”  for  data  transfer 

6 

Notify  the  user  community  by  email  and  by  amending  the  list  of 
registered  fleet  logistics  information  systems 

7 

Notify  CM  that  the  system's  process  model  and  data  model  have  been 
integrated  into  the  fleet  logistics  DA  enterprise  model. 
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8.8.  Modifications  to  and  Exemptions  from  Data  Standards 


What  A  modification  is  a  request  to  change  a  metadata  standard.  A  modification  is 

Constitutes  a  most  often  a  request  to  change  the  definition,  domain,  or  other  characteristics  of 

Modification?  a  standard  data  entity  or  element.  A  modification  can  also  request  creation  of  a 

new  standard  data  entity  or  element. 


Developers  and  maintainers  prepare  modification  requests  in  accordance  with 
Section  3.3  for  entities  and  relationships,  and  with  Section  4.3  for  data  elements. 
Use  the  Metadata  Submittal  Identifier  (Appendix  D)  as  a  cover  for  the  request 
materials.  Fleet  logistics  DA  reviews  requests  in  accordance  with  Section  3.4  for 
entities  and  with  Section  4.4  for  data  elements.  Data  quality  criteria  used  in 
these  reviews  are  provided  in  Section  8.6.  Fleet  logistics  DA  implements 
approved  modifications  in  the  metadata  repository  in  accordance  with  Section 
4.5  and  Section  7. 


When  is  a  A  modification  of  the  standard  is  required  if  the  application’s  intended  use  will 
Modification  make  the  entity,  relationship,  or  data  element  slightly  different  and  therefore  not 
Required?  transparently  shareable.  For  example,  an  application’s  business  rule  that  places 
special  restrictions  (such  as  requiring  additional  approvals)  before  creating  or 
changing  a  data  value  may  not  require  a  modification.  However,  if  the 
application’s  business  rule  changes  the  meaning  or  context  of  the  data  element  so 
that  it  is  not  interchangeable  with  other  instances  of  the  data  element  in  other 
systems  (such  as  a  refinement  in  the  definition  or  modification  of  the  domain), 
then  a  modification  should  be  requested. 

When  in  doubt  regarding  the  effect  of  an  application’s  treatment  of  a  data 
element,  consult  the  appropriate  data  steward  or  information  class  proponent. 


What 

Constitutes 

an 

Exemption? 


An  exemption  is  granted  by  the  fleet  logistics  Data  Administrator  for  a  specific 
data  element  as  it  is  used  on  a  specific  system.  Exemptions  are  rare.  The  most 
common  basis  for  exemption  is  a  finding  that  the  nonstandard  data  element, 
relationship,  or  entity  is  unlikely  to  be  subject  to  data  sharing  within  the  current 
long-range  planning  horizon. 
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8.8.  Modifications  to  and  Exemptions  from  Data  Standards, 

Continued 


Eligibility  for  To  qualify  a  request  for  an  exemption,  the  requesting  developer  must 
an  Exemption  demonstrate  that  the  data  entity  or  element  is; 

•  Truly  unique  to  this  application 

•  Not  likely  to  be  used  in  a  report  or  query 

•  Not  significant  or  useful  outside  the  application 

The  request  is  subject  to  review  by  fleet  logistics  DA  for  data  standards  merit, 
and  by  the  appropriate  data  steward(s)  for  functional  merit. 


Eligibility  for  To  qualify  a  request  for  a  modification,  the  requesting  developer  must 
a  Modification  demonstrate  that  the  requested  change  to  the  standard  data  entity  or  element  is: 

•  Necessary  to  support  the  application's  requirements,  or  is  required  to  work 
within  the  limitations  of  the  technology  that  has  been  approved  for  building 
the  application. 

•  Compliant  with  the  analysis,  level  of  detail,  quality,  and  format  requirements 
so  that  it  is  consistent  with  similar  standard  metadata. 

•  Functionally  accurate,  representing  "best  practice"  and  conformance  to  all 
Coast  Guard  policies  and  regulations,  and  is  not  merely  driven  by  local 
practice. 

The  request  is  subject  to  review  by  fleet  logistics  DA  for  data  standards  merit, 

and  by  the  appropriate  data  steward(s)  for  functional  merit. 


Submittal  of 

Metadata 

Requests 


When  the  developer  determines  that  no  current  standard  data  element  can  be 
utilized,  the  developer  submits  a  request.  The  request  can  be  for: 

•  Creation  of  a  new  standard  data  entity  or  data  element 

•  Modification  of  an  existing  entity  or  element  by  changing  the  definition, 
modifying  attributes,  or  expanding  domains. 

•  Exemption  from  the  requirement  to  standardize  a  specific  entity  or  element 
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8.8.  Modifications  to  and  Exemptions  from  Data  Standards, 

Continued 


Preparation  of  Prepare  the  request  using  the  fleet  logistics  Metadata  Submittal  Identifier  (Appendix 
Metadata  D),  or  the  authorized  electronic  equivalent. 

Requests 

At  a  minimum,  the  request  must  contain  the  following  information: 

•  Identification  of  the  program,  application  system  and  Computer  System 
Configuration  Item  (CSCI)  for  which  the  request  is  made. 

•  Contact  information,  including  the  information  systems  engineer  or  database 
analyst  who  determined  the  need  for  the  request. 

•  Name  of  the  standard  entity  that  most  closely  matches  the  request. 

•  Situation,  example  as  to  why  this  standard  element  must  be  created, 
modified,  or  exempted. 


Processing  Fleet  logistics  DA  processes  exemption  requests  as  follows: 

and  Review  of 

Exemption 

Requests 


Step 

Action 

1 

Check  the  existing  data  element  or  data  elements  noted  by  the  developer 
as  the  closest  match,  and  compare  the  items  in  these  data  elements  to 
those  of  the  data  element  submitted  by  the  developer 

2 

Determine  the  accuracy  of  the  developer's  request 

3 

Provide  a  justification  and  response  to  the  developer's  request 

4 

Take  additional  actions  and  notify  parties  as  necessary  to  implement  the 
decision. 

Review 

Current 

Exemptions 


Fleet  logistics  DA  reviews  and  evaluates  exemptions  and  waivers  as  follows: 


Step 

Action 

1 

Check  all  exemptions  according  to  the  review  process  as  described  in 
"Review  and  Accept  Information  Systems  Metadata" 

2 

Suggest  changes  in  status  to  the  Data  Steward  and  system  developer(s) 

3 

Implement  change  based  on  response  by  Data  Steward  and  developers(s) 

4 

Inform  developer  of  requirement  to  change  their  local  data  element 
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8.9.  Control  Access  to  Non-Public  Information 


Introduction  Data  security  is  administered  by  personnel  other  than  in  Data  Administration,  but 
identification  of  data  ownership  and  levels  of  data  protection  starts  with  data 
administration.  Data  security  ensures  appropriate  and  authorized  access  to  data. 
Appropriate  data  security  measures  are  part  of  the  qualification  required  for  fleet 
logistics  information  systems  to  share  data  with  systems  of  other  agencies.  Data 
security  protects  the  information  resource  from  unauthorized  access,  and  thereby 
prevents  misuse  of  or  damage  to  data  in  this  system. 

Data  security  is  implemented  in  the  application  software,  and  in  system 
administration.  The  definitions  of  data  ownership  and  access  that  are  provided  in 
data  definition  and  standardization  form  the  basis  for  security  provisions  in 
application  software  development  and  for  appropriate  and  effective  security 
administration.  Complete  and  accurate  metadata,  therefore,  provides  one  of 
several  critical  components  for  effective  data  security. 


The  Security 
Component  of 
Data 

Administration 


The  security  component  of  data  administration  includes  the  following  : 

•  Risk  analysis  from  process  model 

•  Interface  analysis  from  the  logical  data  model 

•  Data  element  definition  fields  for  data  restriction  and  ownership 

•  Equivalent  controls  to  enable  data  sharing  with  DoD  systems 


Continued  on  next  page 
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8.9.  Control  Access  to  Non-Public  Information,  Continued 


Security  The  Coast  Guard  sometimes  requires  specific  security  measures  to  protect 

Requirements  information,  whether  in  hardcopy  or  digital  form.  Constraints  and  requirements 
for  data  access  come  from  a  number  of  sources,  including  the  following: 

•  Laws  of  the  United  States 

•  DOT  and  Coast  Guard  regulations 

•  Security  requirements  of  other  agencies 

•  Security  classifications  for  DoD-related  data 

•  Coast  Guard  information  systems  policy 

•  Security  for  aggregated  data 

•  Privacy  Act 

•  Freedom  of  Information  Act 

•  Procurement  sensitivity 

•  Protection  of  vendors'  proprietary  information 

•  Work-in-process  data  (incomplete,  scratchpad,  personal  use,  etc.) 

CG  information  security  guidance  is  provided  by  COMDTINST  5500.13, 
Automated  Information  System  (AIS)  Security,  and  COMDTINST  5510.21, 
Information  Security  Program.  The  DA  role  is  simply  to  capture  and  convey  the 
appropriate  access  restriction  as  part  of  the  data  element's  definition. 


Continued  on  next  page 
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8.9.  Control  Access  to  Non-Public  Information,  Continued 


Life  Cycle 
Requirements 


Data  security  and  integrity  should  be  engineered  into  the  initial  analysis  and 
design  of  an  information  system.  Along  with  the  other  metadata  for  a  model  and 
or  data  element,  this  will  ensure  that  the  overall  DA  requirements  are  part  of  the 
system  at  the  outset,  will  highlight  any  discrepancies  or  deficiencies  in  the  design 
as  it  develops,  and  will  avoid  massive  review  and  rework. 

The  following  are  measures  to  include  data  security  requirements  at  each  step  of 
the  life  cycle  development  of  a  system: 


Phase(s) 


Requirements 
Analysis  and  System 
Design 


Subsystem 

Requirements 

Analysis 


Data  Security  Action 


1 .  Review  all  pertinent  security  doc.  sources  for  rqts 

2.  For  each  entity,  apply  the  requirements  from 
security  documents  to  determine  access  restrictions 


1 .  Review  all  pertinent  security  doc.  sources  for  rqts 

2.  For  each  subsystem,  apply  the  rqts  from  security 
docs  to  determine  access  restrictions 


Detailed  Design 


1 .  Review  all  pertinent  security  document  sources  for 
requirements 

2.  For  each  data  element,  apply  the  rqts  from  security 
docs  to  determine  access  restrictions 


1 .  Apply  software  design  security  rqts 

2.  Devise  test  cases  for  types  of  security  procedures 
and  test  their  practical  application 


1 .  Analyze  all  security  features  of  all  components  of 
the  system  and  ensure  that  they  are  mutually 
compatible 

2.  Devise  test  cases  for  types  of  security  procedures 
and  test  their  practical  application 

3.  Review  results  and  incorporate  into  procedures 


1 .  Analyze  the  security  features  of  the  entire  system 
and  ensure  that  they  are  compatible  with  the 
information  system's  security  features 

2.  Incorporate  any  changes  based  on  this  analysis 

3.  Devise  field  test  for  types  of  security  procedures 
and  test  their  practical  application 


At  each  step  of  the  life  cycle  development,  enforcement  points  and  actions  must 
be  defined  and  executed.  This  will  ensure  that  security  classification  and  other 
access  restrictions  are  documented  as  part  of  data  element  definitions. 


Software  Coding 
and  Testing 


System  Integration 
and  Acceptance 
Testing 


Implementation 

Procedure 


8-37 


Ensure  Data  Quality 


8.9.  Control  Access  to  Non-Public  Information,  Continued 


Data  security  metadata  attributes  will  only  meet  the  CG’s  needs  if  they  reflect 
current  CG  security  requirements.  Periodic  audits  of  the  security  attributes  may 
show  that  some  attributes  were  incorrectly  defined,  or  need  to  be  modified  due  to 
current  requirements.  Discrepancies  in  the  data  security  attributes  must  be 
changed  accordingly. 

The  data  security  audit  process  and  evaluation  of  internal  controls  is  done  as 
follows: 

1 .  Review  all  security-related  metadata  in  the  system  to  see  if  meets  current  CG 
information  security  requirements  (COMDTINST  5510.21) 

2.  Check  the  security-related  business  rules  and  validity  checking  as 
implemented  in  the  software  code  and  system  performance 

3.  Test  access  permissions  enforcement  for  all  user  categories  and  privileges 

4.  Prepare  a  discrepancy  report  (or  the  appropriate  test  results  document)  for 
each  problem  found. 


Data  Security 
Audit 
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8.10.  Risk 


Introduction 


Risk  Analysis 


Risk  Analysis 
Procedures 


Analysis  Process 


Before  defining  the  security  attributes  for  an  entity,  risk  analysis  for  that  entity 
must  be  conducted.  Risk  analysis  will  generate  the  requirements  that  the 
attribute  definition  must  meet.  The  analysis  includes: 

•  Strategic  data  planning 

•  Data  model  analysis 

•  Data  security  requirements  review  (define  security  requirements)  process 

Risk  analysis  should  be  performed  against  those  security  requirements  sources 
listed  at  the  beginning  of  this  section.  In  the  case  of  an  entity  meeting  the  needs 
multiple  security  sources,  the  attribute  should  be  defined  according  to  the 
requirement  with  the  highest  level  of  security. 


Risk  analysis  assesses  the  data  security  and  integrity  risks  to  an  application 
system.  Risk  analysis  examines  the  following  potential  exposures: 

•  Unauthorized  access  to  sensitive,  classified,  or  otherwise  non-public  data 

•  Impact  of  unauthorized  change  or  damage  to  data  values 

•  Implications  of  access  to  aggregated  data 

This  risk  analysis  will  contribute  to  DA  support  of  system  security  requirements. 


Data  security  risk  analysis  procedures  include  the  following  general  steps: 


Step 

Action 

1 

Review  of  Strategic  Data  Plan  and  design  documents.  Review  Concept 
of  Operations,  System  Specification,  and  requirements  documents,  and 
data  requirements,  interfaces,  etc.  for  security  implications. 

2. 

Review  Business  Process.  In  the  business  process  model  and  other 
process  analysis  documents,  identify  the  points  at  which  the  data  is 
vulnerable,  including  user  access,  data  transfer,  unattended  workstations, 
and  interface  to  non-CG  systems. 

3. 

Data  Model  Analysis.  Identify  those  entities  and  relationships  which  are 
addressed  in  data  security  requirements  sources,  metadata  conflicts. 
Identify  the  legal  requirements  and  potential  misuse  for  individual 
records  aggregated  (rolled-up)  data,  and  specific  combinations  of  data 
values. 

4. 

Data  Security  Requirements  Design  Process.  Review  analysis  against 
requirements  sources,  review  milestones,  and  implementation  plan. 

5. 

Risk  Analysis  on  Submitted  Systems  Designs.  Review  all  submitted 
models  against  the  business  process  model’s  security  rules. 

Continued  on  next  page 
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8.10.  Risk 


Wider  Risk 
Analysis 


Interface  to 

Other 

Agencies 


Metadata  for 

Access 

Restrictions 


Indicating 
Data  Access 
Restrictions 


Analysis  Process,  Continued 


Risk  analysis  should  also  be  performed  on  current  systems  and  interfaces  as  well 
as  aggregated,  cross-system  information  resources.  The  results  of  these  analyses 
should  in  turn  be  applied  to  the  risk  analysis  of  the  process  and  data  models. 


Because  fleet  logistics  business  processes  use  resources  from  DoD  and  allied 
agencies,  the  fleet  logistics  standard  provides  for  data  interfaces  to  the 
information  systems  of  those  agencies.  When  defining  the  process  and  data 
models  for  fleet  logistics,  the  data  model  design  must  all  address  the  security 
requirements  for  sharing  data  with  DoD  and  its  allied  agencies. 


The  CG  deals  with  many  kinds  of  sensitive  information,  including  national 
security,  law  enforcement,  procurement,  vendor-proprietary,  and  Privacy  Act 
restrictions.  For  each  kind  of  sensitive  information,  a  set  of  access  restrictions 
apply.  For  some  kinds,  the  critical  issue  is  access  for  changing  the  data.  For 
most  kinds,  reading  the  data  is  restricted  also.  For  a  sensitive  or  classified  entity, 
the  restriction  applies  across  application  systems  and  for  all  sites  and  computer 
systems.  Classified  entities  carry  these  enterprise-wide  access  restrictions  in 
their  metadata. 

Implementing  the  restriction  in  software  is  the  responsibility  of  each  application 
developer.  Granting  access  to  individuals  is  the  responsibility  of  system 
administrators.  Identifying  categories  of  restricted  information  is  the 
responsibility  of  policy  makers  and  security  specialists.  The  contribution  of  data 
administration  is  to  record  the  restriction  in  the  standard  metadata,  so  that  each 
application  developer  and  system  administrator  can  treat  the  restricted 
information  consistently. 


In  most  CASE  tools,  data  access  will  have  to  be  included  in  the  definition  or  in  a 
comment  field.  Responsibility  should  include  the  following  facts: 

•  Functional  area  that  creates  records  (CREATED  BY  aaa) 

•  Functional  area  that  updates  records  (UPDATED  BY  bbb) 

•  Exceptions,  other  areas  that  sometimes  create  or  update  records  (ALSO 
UPDATED  BY  ddd  WHEN  <conditions>) 

•  Mission  area  groups  that  are  authorized  to  use  the  data  values  (USED  BY 
eee),  or  criteria  for  determining  need  to  know  (NEED  ESTABLISHED  BY 
<criteria>) 


Continued  on  next  page 


8-40 


Ensure  Data  Quality 


8.10.  Risk  Analysis  Process,  continued 

Level  of  Detail  In  most  cases,  enterprise-wide  restricted  entities  will  form  only  a  part  of  the  data 
that  requires  access  restriction.  A  restriction  indicator  in  the  metadata  will 
indicate  only  the  data  that  is  always  restricted.  Additional  types  of  information 
fall  under  the  various  types  of  restriction  when  they  are  used  in  combination 
(aggregated  data),  or  at  a  specific  time  (procurement  sensitive),  or  contain 
specific  values  (HAZMAT  right-to-know),  for  example. 

The  restriction  information  carried  in  a  data  entity  definition  should  indicate: 

•  Nature  of  the  restriction  (which  law  or  policy  applies) 

•  Level  of  the  restriction  for  modifying  the  data  values 

•  Level  of  the  restriction  for  reading  the  data  values 


Access  to  Users,  groups  of  users,  or  systems  may  have  different  needs  for  accessing  an 

Information  entity  or  data  element.  For  some  entities  or  data  elements,  a  user  type  may  only 

need  to  read  and  use  the  associated  data,  where  another  user  type  might  also  be 
able  to  edit  and  delete  that  data.  Restricting  the  action  performed  on  data  should 
be  based  on  security  requirements  as  defined  for  each  security  analysis 
checkpoint  within  the  life  cycle  development  of  a  system.  These  analyses,  of 
course,  should  meet  the  fleet  logistics  DA  security  requirements  for  that  entity  or 
data  element. 


Need  to  Know  Rules  for  determining  need  to  know  and  appropriate  access  permissions  are  as 

follows: 

1 .  Refer  to  security  sources  for  the  requirements  that  pertain  to  an  entity  or 
data  element 

2.  Determine  the  security  requirements  for  the  aggregation  of  data  and 
interfaces  to  other  systems 

3.  Determine  the  group(s)  of  users  that  meet  the  security  requirements  for 
access  to  the  entity  or  data  element 

4.  Record  and  submit  the  metadata  for  access  as  appropriate,  including  group 
name  (by  Data  Steward,  information  system,  etc.)  and  associated  R,W,  E,  D 
privileges. 
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8.11.  Ensure  System-Wide  Data  Synchronization 


Introduction  Data  synchronization  involves  the  timing  relationship  one  entity  or  data  element 
may  have  with  another  set  of  entities  or  data  elements.  The  goal  of  the  fleet 
logistics  DA  effort  is  to  improve  the  overall  system-wide  synchronization  of 
related  fleet  logistics  systems,  thus  ensuring  the  reliability  of  the  data  within  the 
system. 

Synchroniza-  Good  data  synchronization  means  reading  a  data  item  after  it  has  been  updated, 
tion  to  obtain  accurate  and  timely  values.  Synchronization  includes  both  when  the 

data  is  read,  and  how  often  it  is  read.  Reading  at  the  wrong  time  (such  as  just 
before  the  field  is  updated)  yields  incorrect  or  untimely  data.  Reading  too  often 
or  not  frequently  enough  can  yield  inaccurate  data,  and  can  waste  processing 
time.  Updating  a  value  at  the  wrong  time  is  useless  if  another  program  writes 
over  (clobbers)  the  update  before  it  can  be  used.  A  well-synchronized  data- 
gathering  program  will  read  data  soon  after  it  is  updated,  and  will  be  scheduled  to 
read  the  data  no  more  frequently  than  it  is  updated. 

Benefits  of  If  timely  updating  of  data  were  the  only  requirement  for  proper  synchronization. 
Accurate  Data  the  metadata  analysis  and  definition  for  synchronization  would  be  a  relatively 
Synchroniza-  simple  process.  If  this  were  the  case,  a  data  user  would  know  how  accurate  that 
tion  data  was  simply  based  on  the  minimum  requirements  for  updating  that  data. 

However,  especially  for  a  multi-system  enterprise,  some  data  may  be  dependent 
upon  the  timely  input  made  from  other  data  on  a  remote  system.  In  conjunction 
with  timeliness  metadata,  additional  metadata  identifying  the  synchronization 
requirements  would  further  refine  the  accuracy  and  reliability  of  the  data.  The 
more  accurate  the  data,  the  better  prepared  is  to  user  to  better  judge  what  action 
should  be  performed  on  that  data. 

Synchroniza-  Synchronization  requirements  are  derived  from  the  process  model  and  the  data 
tion  model  by  analysis  of: 

Requirements 

•  Flow  of  data  (interactions,  dependencies) 

•  Business  rules 

•  Use  and  frequency  of  data  for  roll-up,  cross-system  reporting  and  reference 

•  Schedules  for  release  of  time-dependent  data  values  for  general  use 

Continued  on  next  page 
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8.1 1 .  Ensure  System-Wide  Data  Synchronization,  Continued 


Cycle  Time  The  cycle  time  for  a  data  entity  is  the  period  between  updates,  that  is  the  time 
between  scheduled  changes.  Even  a  continuous  stream  of  data  has  a  cycle  time. 
A  monthly  status  report  would  have  a  cycle  time  of  one  month.  An  electronic 
signal  might  have  a  cycle  time  of  a  hundredth  of  a  second. 

Refresh  Cycle  In  electronic  systems,  the  frequency  with  which  a  value  is  updated  in  a  given 
time 

Examples',  screen  refresh  rate  of  72  times  per  second;  network  polling  rate  of  12 
times  per  minute;  identification  broadcast  of  once  every  20  minutes 

Data  Transfer  In  information  systems,  the  frequency  in  which  a  value  or  data  set  is  transferred 

Cycle  or  broadcast.  This  refers  to  the  time  lapse  between  the  start  of  one  transfer  and 

the  start  of  the  next. 

Example:  position  of  a  target  on  a  radar  screen  on  one  sweep  compared  to  the 
next. 


System  Run  In  automated  or  manual  systems,  the  time  between  the  end  of  a  processing  cycle 

or  Process  (such  as  payments,  requisition  processing,  or  personnel  status  change)  and  the 

Cycle  end  of  the  next  cycle.  This  cycle  time  indicates  how  often  the  process  requires 

input  data,  and  how  often  its  product  data  will  be  updated. 

Example:  Time  between  submitting  a  change  of  address  for  a  distribution  list  and 
the  issue  that  is  mailed  with  the  corrected  address. 


Management  In  a  business  process,  the  time  between  the  completion  of  a  task  or  phase,  and  the 
Reporting  and  end  of  the  next  cycle  of  the  same  type.  This  cycle  indicates  when  and  how  often 
Decision  the  business  process  requires  and/or  produces  information. 

Cycle 

Examples:  Project  status  reporting,  review  and  approval  cycles,  budgeting 
cycles,  and  project  phases. 

Continued  on  next  page 
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8.1 1.  Ensure  System-Wide  Data  Synchronization,  continued 


Levels  of  The  different  data  synchronization  cycles  are  arranged  as  hierarchically 

Synchroniza-  dependent  levels,  as  shown  in  the  following  diagram: 

tion 

Machine  update  cycle 
Data  transfer  cycle 
System  nin/process  cycle 
Management  reporting/decision  cycle 

Each  lower  level  of  synchronization  cannot  be  recycled  until  the  higher  level  is 
recycled.  Synchronization  metadata  rules  for  one  level  thus  make  take  into 
account  the  rules  for  the  immediately  higher  level.  When  analyzing  the 
relationship  of  one  level  to  the  next,  system  designers  may  find  that  the 
timeliness  metadata  for  a  data  entity  or  element  should  be  modified  to  ensure 
accuracy. 


Documenting 
Synchroniza¬ 
tion  Require¬ 
ments  in 
Metadata 


Document  synchronization  metadata  as  follows: 

1 .  Identify  the  timeliness  requirements  for  the  update  of  a  data  entity  or  data 
element  as  defined  by  the  process  and  data  models 

2.  Identify  those  data  entities  and/or  elements,  and  the  relationships  to  these 
other  data  entities  and  elements,  which  must  provide  the  data  entity  or 
element  with  input  before  updating  is  performed. 

3.  Identify  the  system  run  cycle  times. 

4.  Identify  the  data  transfer  cycle  times. 

5.  Identify  the  machine  update  cycle  times. 

6.  Based  on  a  logic  algorithm,  modify  the  data  entity  or  data  element 
timeliness  metadata,  if  necessary. 


Review  of 
Synchroniza¬ 
tion 

Requirements 


Identification  of  data  synchronization  requirements  starts  with  review  of  the 
application's  data  model.  This  review  includes  external  synchronization 
(interfaces  with  other  systems)  and  internal  synchronization  (updates  and  uses 
within  the  application). 


Continued  on  next  page 
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8.11.  Ensure  System-Wide  Data  Synchronization,  Continued 


Assess 

Requirements 


Review  the  application's  data  model  using  the  following  procedure: 

1 .  Identify  the  synchronization  requirements 

2.  Verify  the  timeliness  and  synchronization  metadata  rules  based  on  the 
requirements 

3.  Send  any  change  requests  to  the  DA  repository  operator  for  recording. 


Review  The  data  synchronization  definitions  should  be  reviewed  when  reviewing  the 

Definitions  process  model  and/or  data  model.  Any  changes  should  be  put  through  the 
repository  CM  process. 


Raise  System  designers  should  always  be  cognizant  of  synchronization  issues  when 

Synchroniza-  performing  system  design.  Because  the  overall  goal  of  the  fleet  logistics  DA 
tion  Issues  effort  is  to  manage  data  across  different  systems,  data  synchronization  will  most 
certainly  always  be  a  factor.  Bear  in  mind  any  information  you  may  receive  on 
changes  to  the  information  system  platform,  as  these  will  probably  affect  the  data 
synchronization  rules. 


Verify 

Synchronized 
Update  of 
Data  Values 


Test  specifications  should  be  devised  to  verify  that  the  synchronization  rules  for 
data  values  is  accurate.  Any  test  failures  should  be  documented  and  run  through 
the  repository  CM  process. 
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8.12.  Implement  Data  Integrity  Measures 


introduction  Data  integrity,  as  with  data  quality,  increases  as  the  process  for  analyzing, 

designing,  and  implementing  required  metadata  is  improved.  Specifically,  data 
security  and  data  auditing  impact  data  integrity  most  directly. 


Preventing 
Unauthorized 
Changes  to 
Data  Vaiues 


A  main  component  of  data  integrity  are  the  implementation  of  data  security 
procedures,  as  described  in  the  subsection  "Assess  Risk  and  Control  Access  to 
Non-Public  Information."  Implementation  of  data  security  procedures  should 
prevent  the  great  majority  of  data  errors.  With  an  appropriate  data  security 
process  in  place,  data  errors  will  for  the  most  part  be  inadvertent  and  relatively 
minor.  The  better  the  data  security  system,  the  fewer  the  major  problems  in  data 
integrity,  and  thus  the  easier  it  will  be  to  recover  from  these  major  problems. 


The  following  data  security  actions  directly  affect  data  integrity: 

•  Documentation  of  the  restriction  requirement  in  the  entity  definition. 

•  Implementation  of  the  restriction  in  each  application  where  the  data  item  is 
changed. 

•  Providing  authorized  access  to  individuals  through  security  administration. 


Distribution  Some  standard  data  elements  will  change  attributes  and  definitions  over  time,  and 
and  Version  the  repository  will  track  these  changes  as  described  in  Section  7.  The  purpose  of 

Control  “impact  analysis”  is  to  assess  the  effects  of  a  proposed  change  and  to  identify 

which  standard  systems  will  require  modification  to  support  the  change.  After  a 
metadata  change  is  accepted,  there  will  be  a  period  of  one  to  two  years  when 
some  systems  have  been  upgraded  to  support  the  change,  while  others  have  not. 

It  is  important,  then,  to  know  which  version  of  each  system’s  application 
software  supports  which  version  of  each  standard  data  element  it  uses.  CM  will 
provide  this  mapping  of  application  software  versions  to  data  element  versions. 

For  some  critical  data  elements  and/or  significant  changes,  the  change  will  be 
implemented  by  “effectivity  date,”  so  that  all  systems  switch  over  to  the  new 
version  simultaneously. 


Data  Tracking  Statistics  should  be  compiled  that  provide  a  detailed  measures  of  data  accuracy, 
TechniQue  data  consistency,  and  process  cycle  times.  These  statistics  should  be  designed  to 

and  Metrics  answer  to  the  specific  data  integrity  audit  procedures.  The  data  tracking 

techniques  should  include  metrics  for  a  system  of  measurement  and  statistical 
control. 


Continued  on  next  page 
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8.12.  implement  Data  Integrity  Measures,  continued 


Purposes  of 
Data  Integrity 
Audit 


At  regular  intervals,  data  integrity  audits  should  be  performed.  Such  audits: 

•  Ensure  that  only  organizations  identified  by  Data  Stewards  will  create  or 
update  specified  data  values 

•  Ensure  that  reliability,  accuracy,  and  ease-of-access  of  standard  data  meets 
the  needs  of  users. 

•  Detect  corruption  of  data  (providing  data  quality  checks  at  an  information 
resource  level) 

•  Provide  a  means  for  ongoing  checking  of  data  integrity,  (e.g.,  edit  checks, 
filters,  and  criterion-referenced  metrics) 


Data  Integrity  Data  integrity  audits  should  be  based  on  the  following  assessment  points: 

Audit 

•  Data  to  be  used  as  input  to  a  critical  process 

•  Validate  results  of  processing 

•  Validate  output 


Life  Cycle  Perform  the  above  procedure  at  the  following  points  in  the  system 

Review,  Audit  design/development  life  cycle: 

Points 

•  Requirements  Analysis 

•  System  Design 

•  Detailed  Design 

•  Software  Coding  and  Testing 

•  System  Integration  and  Acceptance  Testing 

•  Implementation 


Improvement  Throughout  the  data  quality  audit  process,  improvement  opportunities  should  be 
identified  for  the  standards/DA  program  from  individual  data  elements  up 
through  process  models,  fleet  logistics  DA  will  assess  the  results  of  data  quality 
audits  for  the  following  types  of  actions: 

•  Selecting  improvement  opportunities  to  pursue,  and  setting  objectives 

•  Making  changes  and  sustaining  gains 

•  Process  simulation  -  reduces  the  number  of  choices  to  a  manageable  level. 
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8.13.  Establish  Consistent  Definition  of  Terms  across 
Systems 


Purpose  An  enterprise-wide  set  of  data  definitions  is  achievable  only  if  the  various 

functional  areas  agree  on  common  meanings  for  the  information  they  share. 


Responsibility  The  fleet  logistics  DA  office  will  compile  and  publish  a  Dictionary  of  Metadata 
Terms  as  part  of  its  data  standardization  function. 


Dictionary  for  The  fleet  logistics  DA  repository  will  collect  and  publish  a  Dictionary  of 
Metadata  Metadata  Terms.  These  terms  and  definitions  shall  be  used  wherever  applicable 

Terms  to  define  data  and  processes  to  convey  the  same  meaning  to  all  users  of  the  data. 


What  are  Key  Key  terms  are  nouns,  verbs,  adjectives,  and  adverbs  that  are  allocated  specific 
Terms?  meaning  in  metadata  definitions.  These  terms  are  to  be  used  in  definitions  only 

in  the  meaning  that  is  indicated  in  the  Dictionary  of  Metadata  Terms. 


Standard 
Definition 
Process  for 
Terms 


The  following  are  the  general  phases  of  the  standard  definition  process  for  terms: 

1.  The  process  is  begun  with  a  request  for  new  term  or  expansion  of  definition 
for  a  standard  term 

2.  Review  by  fleet  logistics  DA  for  duplication,  relevance,  completeness,  and 
consistency  with  definitions  used  by  allied  agencies 

3.  Review  by  designated  data  steward(s) 

4.  Release  of  approved  term  (on-line  and  in  next  published  version  of 
Dictionary) 
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8.14.  Improve  the  Data  Quality  Program 


Purpose  The  processes  and  standards  used  to  achieve  data  quality  must  improve  and 

evolve.  This  continuous  improvement  effort  will  improve  the  reliability  and 
usefulness  of  fleet  logistics  DA  data  standards  by  refining  the  criteria  and 
processes  for  standardization  and  administration. 

Guidance  for  CG  quality  improvement  is  provided  in  COMDTINST  5224.8, 
Coast  Guard  Total  Quality  Management  (TQM)  Organizational  Structure  and 
Training  Strategy 


Continuous 
Improvement 
of  the 
Standards 
Program 


Improvement  of  data  administration  processes  will  require  the  following: 

•  A  Quality  Officer,  who  serves  as  the  point  of  contact  for  quality  issues,  who 
monitors  the  quality  of  the  standard  data  resource,  and  who  provides 
information  to  the  Data  Quality  Action  Team. 

•  A  Data  Quality  Action  Team  (QAT),  representing  the  developer,  program 
management,  data  administration,  data  stewardship,  and  mission  area  (data 
user)  components  of  the  information  life  cycle. 

•  A  monitoring  and  reporting  process,  to  anticipate  problems  by  analysis. 


Continued  on  next  page 
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8.14.  Improve  the  Data  Quality  Program,  continued 


Record  and  The  fleet  logistics  DA  will  designate  a  Quality  Officer  as  a  data  quality  and 
Track  Data  process  improvement  point  of  contact.  The  Quality  Officer  shall  collect 
Quality  Issues  information  and  seek  opportunities  for  process  improvement,  including  the 
following: 

•  Recurring  and  unresolved  discrepancies  between  standards  and  submitted 
metadata 

•  Ambiguities  in  information  class  boundaries  and  data  stewardship 
responsibilities 

•  Metadata  quality  deficiencies 

•  Recommendations  for  improved  processes 

•  Apparent  bottlenecks  in  the  review  and  standardization  process 

For  each  issue  and  opportunity,  the  Quality  Officer  shall: 

•  Document  the  issue  or  opportunity,  and  log  each  for  tracking. 

•  Distribute  the  write-up  for  each  item  to  members  of  the  appropriate  Business 
Process  or  Data  QAT. 

The  Business  Process  or  Data  QAT  in  turn  shall: 

•  Prioritize  the  issues  and  opportunities,  and  aggregate  items  into  larger  issues 
for  problem-solving. 

•  Periodically  review  the  list  to  ensure  attention  to  all  items 

•  Report  to  fleet  logistics  DA  with  recommendations  for  process  improvement, 
and  with  disposition  of  all  traceable  items. 


Tracking  The  fleet  logistics  DA  quality  officer  shall  analyze  the  standardization  process 

Metadata  and  the  standard  data  resource  for  potential  problems  and  opportunities  for 

Quality  improvement.  Findings  shall  be  reported  to  the  fleet  logistics  DA  and  to  the  Data 

Deficiencies  QAT.  Data  quality  problems  include  the  following: 

•  Process-oriented  problems,  including  discrepancies  in  the  standards  and  gaps 
in  the  data  administration  process. 

•  Data  value  problems,  including  reports  of  inaccurate,  corrupt,  or  unusable 
data  from  registered  standard  systems. 

•  Productivity  and  general  quality  problems,  as  indicated  by  metrics,  by 
incident  reports,  and  by  data  sampling,  and  by  data  audits. 


Continued  on  next  page 
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8.14.  improve  the  Data  Quality  Program,  Continued 


Review  and 

Authorization 

of 

Improvements 


The  fleet  logistics  DA  authorizes,  funds,  and  implements  DA  process 
improvement  recommendations.  Improvements  are  to  be  considered  from  at  least 
the  following  sources: 

•  Changes  in  Coast  Guard  information  resources  management  policy 

•  Changes  in  the  information  management  practices  of  allied  agencies 

•  Strategic  data  planning 

•  Program  priorities 

•  Results  of  data  quality  monitoring  and  audits 

•  User  requests  and  recommendations 

•  QAT  and  Quality  Officer  recommendations 
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IMPLEMENT  DATA  STEWARDSHIP 


9.1.  Overview 


Introduction  An  effective  and  representative  data  stewardship  program  is  the  key  to  long-term 
success  of  information  sharing.  Data  stewards,  also  called  information  class 
proponents  (ICPs),  represent  their  respective  areas  of  responsibility  on  behalf  of 
the  entire  enterprise.  Each  data  steward  is  assigned  one  information  class  or  a 
small  number  of  related  information  classes,  to  build  the  necessary  expertise  and 
perspective.  Data  stewardship  is  a  role,  not  a  full-time  job.  Each  data  steward 
represents  the  CG  mission  area  that  has  the  highest  level  of  responsibility  or  most 
frequent  interaction  with  the  data  items  in  the  respective  information  class.  When 
fully  operational,  the  data  stewardship  role  returns  data  definition  authority  to  the 
appropriate  expert  user  communities. 


Data  stewards  and  subject  matter  experts  ensure  the  accuracy,  completeness,  and 
relevance  of  data  element  definitions  and  components  of  the  enterprise  data  model 
that  are  within  their  respective  areas  of  responsibility.  Their  work  ensures  that 
standard  metadata  can  be  used  to  satisfy  data  requirements  throughout  the 
organization. 


The  scope  of  data  stewardship  includes  the  designated  data  stewards,  any  deputy 
data  stewards  that  share  the  responsibility  for  an  information  class,  and  subject 
matter  experts  (SMEs)  who  act  as  consultants  for  specialized  subject  areas  or 
business  processes. 


In  this  Section  This  section  shows  how  data  stewardship  works  to  ensure  the  accuracy,  validity, 
and  usefulness  of  fleet  logistics  shareable  data.  The  program  has  the  following 
major  parts: 


Topic 

Section 

Overview 

9.1 

Introduction  to  Data  Stewardship 

9.2 

Data  Stewardship  Responsibilities 

9.3 

Implementing  a  Data  Stewardship  Program 

9.4 

Data  Stewardship  Skills  and  Training 

9.5 

Access  to  Tools,  Systems,  and  Information 

9.6 

Implement  Data  Stewardship 


9.2.  Introduction  to  Data  Stewardship 


Purpose  of  Data  stewards  and  subject  matter  experts  (SMEs)  are  the  critical  and  ongoing  link 
Data  between  the  people  who  use  the  information  and  the  people  who  create  and 

Stewardship  manage  standard  information  systems.  The  people  who  do  a  particular  type  of  job 
are  the  ones  who  are  closest  to  those  types  of  information  that  are  central  to  their 
specialty.  The  experts  in  that  information  class  know,  from  experience  and 
training,  the  difference  between  similar  technical  terms,  how  to  verify  the  accuracy 
of  data  values,  which  laws  and  regulations  apply  to  certain  information,  which 
information  requires  restricted  access,  and  the  timing  relationships  between 
updated  data  items. 

For  a  data  standard  to  be  useful,  this  insight  must  be  built  into  each  business  rule  in 
the  data  model  and  each  detail  of  each  data  element  definition.  Making  sure  that 
each  data  element  definition  is  complete,  accurate,  and  useful  is  the  role  of  the  data 
steward.  SMEs  support  a  data  steward  by  providing  technical  information  and 
reviewing  data  element  definitions  within  the  SME's  area  of  expertise. 

For  example,  if  "Task  Start  Date"  in  one  system  means  an  approval  or  funding 
date,  and  in  the  other  system  it  means  the  date  the  work  actually  started,  these 
dates  don't  mean  the  same  thing.  To  import  these  dates  with  the  other  task  and 
assignment  information  and  print  a  report  where  all  of  the  tasks  are  sorted  by  "start 
date"  provides  inaccurate  and  misleading  information  -  one  group  of  tasks  is  going 
to  appear  to  have  started  later,  when  the  opposite  may  be  true. 

The  best  way  to  be  sure  that  two  systems  are  storing  sharable  data  is  to  establish  a 
complete,  accurate,  and  useful  data  standard  -  and  then  make  sure  that  all 
information  systems  use  these  standard  data  definitions  before  permitting  them  to 
share  data  values.  Only  then  can  information  systems  share  data  with  the 
assurance  that  data  fields  with  the  same  name  mean  exactly  the  same  thing.  For 
two  items  of  data  from  different  systems  to  be  combined  and  rolled-up  in  a  report, 
they  must  represent  the  same  information. 


Continued  on  next  page 
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9.2.  Introduction  to  Data  Stewardship,  continued 

Role  of  Data  Data  stewards  and  subject  matter  experts  keep  the  standard  data  definitions 
Stewardship  complete,  accurate,  and  useful  over  time.  If  the  standard  data  definitions  are 

useful,  system  developers,  maintainers,  and  users  will  be  less  likely  to  invent  their 
own,  incompatible  definitions.  By  representing  the  community  that  uses  and  is 
responsible  for  each  information  class,  data  stewards  keep  the  standard  data 
definitions  current.  The  tests  of  success  of  a  data  steward  include  the  degree  to 
which: 

•  Information  system  developers  and  maintainers  use  (accurately)  the  standard 
definitions  of  the  steward's  information  class 

•  Newly  developed  or  standardized  applications  use  the  standard  data  elements 
and  model  without  requesting  modifications 

•  Information  is  shared  routinely  and  transparently  between  unlike  systems. 

Figure  9-1  show  the  relationship  of  the  stewardship  role  to  users,  system 
developers  and  maintainers,  and  fleet  logistics  data  administration. 


Data  Stewards  Maintain  their  User  Communities'  Best  Definitions. 
Data  Administration  Maintains  the  Enterprise  Data  Standard. 


Figure  9-1.  Data  Steward  Working  Relationships 
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9.3.  Data  Stewardship  Responsibilities 


Data  Each  data  steward  is  responsible  for  one  or  more  categories  of  information  in  the 

Steward's  enterprise  data  model,  each  referred  to  as  an  information  class.  Within  this 

Scope  of  information  class,  the  assigned  data  steward  has  the  following  seven 

Responsibility  responsibilities; 

1 .  Understand  how  data  is  used  across  the  fleet  logistics  community  and  in  the 
wider  Coast  Guard  enterprise 

2.  Determine  how  standard  (enterprise)  data  could  be  used,  and  participate  in 
strategic  data  planning  to  achieve  optimum  data  use 

3.  Provide  data  standardization  leadership  and  support 

4.  Recruit  and  coordinate  the  participation  of  subject  matter  experts 

5.  Review  metadata  change  requests 

6.  Monitor  data  quality 

7.  Represent  users  of  data  within  the  information  class 


Each  data  steward  performs  these  responsibilities  for  one  or  more  assigned 
information  classes.  The  decisions  regarding  an  information  class  apply  to  all 
instances  of  use  of  data  elements  within  that  information  class  throughout  the 
enterprise.  For  example,  a  decision  regarding  a  personnel-related  data  element 
(such  as  rank  or  occupational  specialty  designation)  would  apply  to  all  standard 
information  systems  in  the  enterprise  that  create,  read,  update,  or  delete  values  of 
that  data  element  —  not  just  personnel  applications.  The  data  stewardship  program 
assumes  that  specialists  in  a  given  functional  area  are  best  qualified  to  define  the 
data  associated  with  that  information  class. 


To  provide  the  best  long-term  decisions  that  accommodate  the  widest  possible 
range  of  current  and  future  applications,  each  data  steward  must  continuously 
gather  information  and  negotiate  metadata  standards  criteria.  A  summary  of  the 
interactions  and  the  kinds  of  information  shared  are  shown  in  Figure  9-2.  The 
information  classes  and  their  respective  proponent  organizations  are  provided  in 
Appendix  C. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  Continued 


Specific  The  following  table  summarizes  the  activities  through  which  each  data  steward 

Stewardship  will  discharge  his/her  data  stewardship  responsibilities. 

Roles 


Responsibility 

Actions 

How  Often 

1.  Understand 
how  data  is  used 

Continually  model  business  processes  to 
reflect  changes  in  requirements. 

Maintain  familiarity  with  CG 
information  systems 

Establish  contacts  in  orgs  with  which  CG 
shares  data  (of  info  class) 

Ongoing  (intensive 
at  start) 

2.  Determine 
how  data  could 
be  used 

Participate  in  inter-organization 
standards  groups. 

Participate  in  strategic  data  planning, 
data  modeling,  process  improvement, 
user  groups 

Identify  data  standardization  rqts.  & 
opportunities  for  data  sharing 

Ongoing  (growing) 

3.  Provide  data 
standardization 
leadership  and 
support 

Advocate  sharing  of  standard  data 

Provide  technical  support  to  users 

Propose  DA  changes  that  lead  to  data 
sharing  between  organizations 

Ongoing  (growing) 

4.  Recruit  & 
coordinate  SMEs 

Identify  areas  requiring  SMEs 

Recruit  SMEs;  replace  w/  duty  cycle 
Consult  SMEs 

Heavy  initial 
activity,  then 
moderate  ongoing 

5.  Review 
metadata  change 
requests 

Review  change  requests 

Track  DEs  "where  used" 

Moderate  after  DS 
program  deployment 

6.  Monitor  data 
quality 

Add  quality/security/synch  attributes  to  all 
reviewed  DEs 

Identify  risky  data  categories 

Monitor  at-risk  data  values 

Moderate  ongoing 

7.  Represent 
data  users 

Review  IS  design  docs 

Participate  in  process  improvement 

Review  training  materials 

Develop  process  &  data  models 

As-needed 

Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  continued 


Data  Steward  Interactions 


Fleet  Logistics 
Data  Administrator 

Process  &  Data  Modeling, 
review  of  data  element  definitions, 
Review  DBDDs,  IDDs,  and 
Data  Conversion  Plans 

Coast  Guard 
Data  Administrator 


CG~wide  data  sharing, 
standards,  impact  of  change^ 

System 
Development 
Team(s) 

Business  processed, 

Definitions 

Maintainers  & 
Administrators 
of  Deployed  Systems 

Current  business  processes, 
data  requirements,  problems 
in  sharing  of  data  values 


Subject  Matter 
Experts 

Specific,  in-depth 
definitions,  reviews, 
technical  support 


Supplier  &  Allied 
Organizations 

Definitions,  standards,  & 
formats  for  data  sharing 


Standards* 
Organizations 

Definitions,  standards,  & 
formats  for  data  sharing 

Professional 
Organizations 

Users  and 
Mission  Area 
Organizations 

Data  requirements, 
definitions,  & 
technical  support 


Figure  9-2.  Data  Stewardship  Information  Exchange 


Stewardship  The  steward’s  key  contribution  to  the  data  administration  program  is  to  ensure  the 

Interactions  quality  and  durability  of  data  item  definitions.  Important  to  success  is  the 

steward’s  ability  to  achieve  an  “enterprise  view.”  Defining  data  from  an  enterprise 
point  of  view  provides  metadata  that  meets  the  needs  of  multiple  applications  and 
business  areas,  and  so  does  not  need  to  be  revised  each  time  a  new  system  is  added 
to  the  enterprise. 

Figure  9-2  suggests  the  kinds  of  insight  that  the  steward  can  gain  from  working 
with  various  organizations  and  stakeholders. 


Detail  for  The  following  seven  paragraphs  provide  detail  for  performance  of  these 

Stewardship  stewardship  roles.  Each  data  steward  should  read  and  understand  these.  While  the 

Roles  stewardship  role  is  not  a  full-time  job,  each  steward’s  enterprise  view  and 

effectiveness  as  an  advocate  will  improve  to  the  degree  he/she  performs  these 
seven  roles. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  Continued 


1.  Understand 
How  Data  is 
Used  in  the 
Enteiprise 


The  most  basic  role  of  a  data  steward  is  to  understand,  as  completely  as  possible, 
how  data  in  general,  and  the  assigned  information  class  in  particular,  is  used 
throughout  the  enteiprise.  "Use"  of  data  includes  data  capture  (creating  new 
values/records),  updating  data,  deleting  or  archiving  unused  data,  and  reading  data 
for  queries,  reports,  or  reference.  Data  stewards  achieve  and  improve  this 
understanding  by: 

•  Becoming  familiar  with  the  capabilities  and  daily  use  of  all  standard  and 
legacy  information  systems  that  use  data  from  the  assigned  information  class 

•  Using  data  modeling  techniques  to  describe  the  relationship  of  information 
among  Coast  Guard  organizations  and  to! from  other  Government  and  private 
organizations,  with  special  attention  to  tracking  all  uses  of  data  from  the 
assigned  information  class 

•  Participation  in  quality  teams  that  define  or  improve  business  processes,  using 
business  process  modeling  methods  and  tools 

•  Contributing  to  strategic  data  planning,  and  to  refinement  of  the  Coast  Guard's 
data  architecture. 

These  experiences,  in  addition  to  contributing  to  efficient  use  of  the  Coast  Guard's 
information  resources,  will  provide  each  data  steward  with  a  foundation  of 
information,  skills,  and  contacts.  This  foundation  will  enable  the  data  steward  to 
make  better-informed  decisions  when  reviewing  data  element  definition  requests. 

It  also  provides  opportunities  to  advocate  and  support  effective  use  of  the 
enterprise  data  resource.  Sections  2  and  3  provide  additional  information 
regarding  this  role. 


Many  potential  data  stewards  have  participated  in  process  improvement  teams  for 
the  processes  that  would  require  their  attention  as  data  stewards.  One  part  of  the 
data  stewardship  role  is  to  continue  this  participation  (after  training  in  data 
modeling  and  data  administration)  with  closer  attention  to  information 
requirements  and  opportunities  for  data  sharing.  COMDTINST  5224.8,  Coast 
Guard  Total  Quality  Management  (TQM)  Organizational  Structure  and  Training 
Strategy  describes  the  types  of  teams  and  participants.  The  combination  of  process 
analysis  and  data  modeling  is  effective  to  improve  understanding  of  a  function  and 
to  develop  significant  improvements. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  Continued 

2.  Determine  Information  that  is  developed  and  stored  in  Coast  Guard  information  systems  is  an 
How  Data  enterprise-wide  asset.  Specific  data  values  should  be  captured  once,  stored  in  a 

Could  Be  standard,  accessible  repository,  and  then  used  as-needed  throughout  the  enterprise. 

Shared  Each  data  steward,  through  familiarity  with  regulations.  Coast  Guard  business 

processes,  and  information  sharing,  will  identify  additional  data  standardization 
requirements.  Each  data  steward,  through  attention  to  the  assigned  information 
class,  will  find  opportunities  for  improved  information  sharing,  data  quality,  and 
data  utilization. 

The  data  steward's  familiarity  with  the  information  class,  including  the  use  of  this 
information  in  other  parts  of  the  Coast  Guard,  will  enable  him/her  to  recognize 
opportunities  for: 

•  Data  sharing 

•  Improving  data  quality 

•  Improving  the  consistency  of  data  qccess  rules 

•  Improving  business  processes. 

This  perspective  will  also  enable  the  data  steward  to  recognize  subtle  problems 
such  as: 

•  Misapplication  of  data  definitions 

•  Corruption  of  data  values 

•  Mis-synchronization  of  data  updates 

•  Duplicate  data  entry 

•  Unauthorized  access  to  restricted  data. 

Each  data  steward  will  take  the  initiative  to  contribute  and  advocate  these 
improvements  and  refinements  in  the  use  of  the  assigned  information  class.  This 
initiative  and  advocacy  will  include  participation  in  business  process  quality 
improvement  teams,  strategic  data  planning  sessions,  information  systems  user 
groups,  and  data  standards  working  groups. 

Section  2,  Data  Administration  Program,  provides  additional  information 
regarding  this  role. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  continued 


3.  Provide 
Metadata 
Leadership 
and  Support 


Each  data  steward  is  a  leader  and  advocate  for  enterprise-wide  use  of  information 
resources.  He  or  she  is  the  most  visible  advocate  of  data  standardization  in  one  or 
more  application  user  communities,  and  is  the  representative  of  the  assigned 
information  class  to  the  information  systems  community.  The  role  of  advocacy 
works  three  ways: 

•  To  the  user  communities,  the  steward  advocates  standard,  shareable  data  and 
promotes  confidence  in  the  standard  data  definitions. 

•  To  the  information  systems  community,  the  steward  advocates  precise  data 
definitions  and  accurate  data  models  that  reflect  the  best  practice  of  the 
respective  user  communities.  This  advocacy  assists  planners  and  designers  to 
understand  why  enterprise-wide  use  requires  a  specific  set  of  definitions. 

•  To  other  enterprises,  the  steward  advocates  common  data  standards  that  permit 
efficient  and  reliable  information  sharing,  and  offers  cooperation  in  metadata 
definition  to  achieve  a  wider  enterprise. 

The  long-term  success  of  the  data  administration  program  depends  directly  on  each 
steward's  success  in  these  three  advocacy  and  leadership  roles.  Each  steward’s 
efforts  to  achieve  an  enterprise  point  of  view  will  determine  whether  fleet  logistics 
standard  data  definitions  will  require  frequent  revisions,  or  are  strategic  and  meet 
the  needs  of  future  standard  systems  without  revision. 


4.  Recruit 
Subject 
Matter 
Experts 


Each  data  steward  is  encouraged  to  multiply  his/her  effectiveness  by  utilizing  the 
specialized  knowledge  of  others.  Specific  areas  within  the  steward's  assigned 
information  class  will  require  specialized  familiarity  and  experience.  In  addition, 
the  participation  of  subject  matter  experts  (SMEs)  will  increase  their  respective 
organizations’  awareness  and  support  of  standard,  shareable  data.  SMEs  serve  as 
consultants  in  the  business  process  modeling,  data  modeling,  and  data  element 
definition  processes.  Each  SME  is  in  a  position,  by  experience,  study,  and/or 
organizational  assignment  to  determine  the  finer  points  of  use,  naming,  applicable 
regulations,  best  standard  practice,  and/or  Coast  Guard  policy  authoritatively  for 
his/her  area  of  expertise. 

Each  data  steward  should  identify  the  specialty  areas  within  the  information  class 
that  may  require  occasional  SME  support.  The  data  steward  will  work  with  the 
DA  to  identify  and  recruit  the  best  available  expert  to  meet  each  specialty 
requirement.  The  data  steward  should  communicate  regularly  with  the  SMEs  in 
the  assigned  information  class,  will  distribute  relevant  material  to  SMEs  for  review 
and  comment,  and  will  arrange  for  transition  and  replacement  of  SMEs  when 
necessary. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  Continued 


5.  Review 
Metadata 
Change 
Requests 


Reviewing  requests  for  data  element  and  data  model  changes  is  the  most  frequent 
activity  of  each  data  steward.  Success  of  the  data  administration  program  is 
improved  by  each  steward’s  enterprise  point  of  view  and  thorough  familiarity  with 
one  or  more  information  classes.  Effective  review  is  based  on  the  steward's 
familiarity  with  the  subject  area,  consultation  with  the  appropriate  SMEs,  and  the 
experience  and  perspective  gained  from  performing  the  stewardship  roles  of 
leadership,  advocacy,  and  support.  Stewards  review  the  following  types  of 
metadata  change  requests: 

•  New  and  proposed  revisions  of  data  element  definitions  and  attributes 

•  Business  rules,  domains  of  values,  data  quality  and  security  issues 

•  Logical  entities  (names,  aliases,  scope) 

•  Relationships 

Metadata  review  is  an  especially  sensitive  and  visible  process  because  the  results 
can  significantly  affect  the  Coast  Guard's  business  processes,  the  shareability  of 
data,  and  the  usefulness  of  information  systems.  Review  of  specific  requests  must 
be  efficient,  fair,  and  quick,  and  must  not  be  perceived  as  a  roadblock  to 
information  systems  development. 

The  steward’s  review  is  the  second  step  in  the  metadata  review  process. 
Developers,  maintainers,  and  others  submit  metadata  change  requests  to  DA, 
where  the  request  is  checked  for  completeness  and  standards  compliance.  DA  then 
identifies  the  information  class(es)  associated  with  the  request  and  forwards  it  to 
the  appropriate  steward(s)  Stewardship  review  begins  at  this  transmittal  from  DA, 
in  the  process  shown  in  Figure  9-3  and  consists  of  the  following  steps: 


Step 

Step  Name 

Steward's  Action 

1 

Receipt  of  review  request 

Log-in  the  date  request  was  received, 
suspense  date,  type  of  request. 

2 

Evaluate  request 

Determine  whether  request  is  unique, 
significant,  and  useful.  Determine 
effect  of  requested  change  on  current 
and  planned  systems  (repository 
“where-used”  report).  Identify  which 
SMEs  should  be  consulted. 

3 

Prepare  and  transmit  to  selected 
SME(s) 

Provide  initial  assessment  of  impact  of 
proposed  change.  Prepare  transmittal; 
send  to  selected  SME(s)  with  due  date. 

4 

Receive  and  evaluate  SME 
recommendations 

Evaluate  SME  responses.  Follow-up 
on  non-responses.  Incorporate  SME 
recommendations  in  decision. 

5 

Develop  recommendation 

Decide  to  reject,  modify,  or  accept  the 
request,  with  justification. 

6 

Transmittal 

Log  and  transmit  the  response  to  DA. 

A  log  worksheet  and  Data  Steward’s  Review  Response  are  provided  in  Appendix  E. 


Continued  on  next  page 
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9.3. 


Data  Stewardship  Responsibilities,  continued 


Data  Stewardship  Review 


Figure  9-3.  Metadata  Review  Process 


Sources  of 

Additional 

Information 


Sections  3,  Integrate  Data  Models,  4,  Define  Data  Elements,  and  9,  Ensure  Data 
Quality,  provide  additional  information  regarding  this  role.  Metadata  life  cycle  stages 
are  defined  in  Section  11. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  continued 


6.  Monitor  The  risks  to  data  quality  multiply  as  more  information  systems  become  part  of  the 

Data  Quality  enterprise  standard  data  resource.  No  one  individual  or  organization  can  monitor 

all  the  possible  risks  to  all  types  of  information.  Each  data  steward  must  use  all 
possible  means  to  anticipate  data  quality  problems,  and  to  detect  inaccurate  or 
corrupted  data  values.  Attention  to  data  quality  by  each  data  steward  for  his/her 
assigned  information  class  provides  a  number  of  monitors,  each  watching  the 
information  resource  from  a  different  perspective.  The  steward’s  position  is  the 
most  visible  data  advocate  in  a  functional  area,  and  so  the  steward  is  a  logical  point 
of  contact  to  collect  and  document  data  quality  problems.  From  this  information, 
the  steward  can  recommend  solutions  that  are  both  technically  appropriate  and 
consistent  with  standard  metadata.  Monitoring  data  quality  can  provide  clues  to 
problems  with  the  data  model,  or  can  point  to  systems  with  inadequate  error 
checking.  The  understanding  gained  through  this  experience  will  help  each  data 
steward  to  appreciate  subtle  interactions  of  data  values,  and  so  will  improve  the 
precision  and  insight  of  the  metadata  review  and  strategic  data  planning  processes. 

Data  integrity  and  security  areas  directly  affect  data  quality.  Each  data  steward 
must  coordinate  with  information  system  database  administrators  to  ensure  data 
integrity  measures  are  consistent  and  adequate,  and  with  network  and  system 
administrators  to  ensure  that  consistent  and  appropriate  data  access  rules  are 
implemented. 

Section  9,  Ensure  Data  Quality,  provides  additional  information  regarding  this 
role,  and  describes  specific  facets  of  data  quality  that  require  stewardship 
attention. 


Continued  on  next  page 
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9.3.  Data  Stewardship  Responsibilities,  Continued 


7.  Represent  A  Coast  Guard  organization  allocates  valuable  time  of  key  staff  for  data 
Data  Users  stewardship  because  this  is  the  best  way  to  ensure  representation.  Information 
systems  are  tools  that  people  use  to  accomplish  their  work  more  efficiently, 
accurately,  completely,  and  consistently.  Every  information  system  is  designed  to 
support  users,  but  regular  review  and  feedback  is  required  to  ensure  an  ongoing 
match  between  system  functions  and  user  requirements.  Precise  definition  of 
standard  data  elements  and  accurate  modeling  of  the  relationships  of  these 
elements  are  critical  to  useful  system  design.  Systems  that  lack  this  attention 
require  expensive  work-arounds  and  later  redesign  before  they  can  be  deployed 
effectively.  By  representing  the  user  communities  associated  with  the  assigned 
information  class,  the  data  steward  ensures  that  all  data  definitions  are  accurate, 
complete,  and  useful,  through  the  following  functions: 

•  Participates  in  process  improvement  action  teams,  both  to  advocate  use  of 
standard  data  and  to  understand  improvements  in  business  processes 

•  Represents  the  information  class  users  in  strategic  data  planning 

•  Reviews  Functional  Descriptions,  Concept  of  Operations,  System 
Specifications,  Interface  Design  Documents,  and  Database  Design  Documents 
for  all  new  or  upgraded  information  systems  that  touch  the  assigned 
information  class 

•  Participates  in  data  administration  briefings  to  system  developers, 
maintainers,  and  administrators,  especially  when  definitions  in  the  assigned 
information  class  are  complex. 

•  Reviews  information  system  training  materials  to  ensure  proper  use  of 
standard  data 

•  Works  with  SMEs,  program  managers,  and  the  chain  of  command  to  develop 
accurate  and  complete  business  process  models  and  data  models,  so  to 
describe  the  community's  true  information  requirements. 

Sections  2  through  8  provide  additional  information  regarding  this  role. 
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9.4.  Implementing  Data  Stewardship 


Scope  of  the  The  scope  of  the  data  stewardship  program  is  driven  by  the  span  of  the  current 
Program  enterprise.  As  the  enterprise  evolves  to  a  wider,  more  inclusive  span,  the 

responsibility  for  data  stewardship  will  change.  The  specific  roles  will  remain,  but 
the  scope  of  organizations  and  missions  within  the  enterprise  will  grow.  For  this 
reason,  the  data  stewardship  program  will  be  in  constant  implementation. 


Organization  Data  stewards  and  subject  matter  experts  (SMEs)  do  not  report  to  the  enterprise 

data  administrator;  rather,  they  represent  their  respective  information  classes  to  the 
data  administrator  and  advocate  for  accurate  and  complete  data  definitions.  Data 
stewards  and  SMEs  take  on  this  role  in  addition  to  their  regular  duties,  to  ensure 
accurate  representation  of  their  respective  areas  in  the  Coast  Guard’s  information 
systems.  This  independence  ensures  that  each  data  steward  will  retain  the  users' 
point  of  view  and  that  the  dialog  between  data  stewards  and  system  developers  and 
maintainers  will  remain  lively,  vital,  and  relevant. 


Evolution  and  At  some  point  in  the  future,  the  fleet  logistics  enteiprise  is  likely  to  be  integrated 
Turnover  with  others,  forming  a  higher-level  cross-functional  enterprise.  To  prepare  for  an 

orderly  transition  to  the  higher-level  enterprise: 

•  Anticipate  integration  by  coordinating  metadata  with  stewards  of  enterprises 
with  which  the  Coast  Guard  shares  data.  Find  out  who  is  the  data  steward  for 
the  equivalent  information  class(es)  in  each  organization,  and  share 
definitions,  change  requests,  impact  assessment,  models,  etc. 

•  Participate  in  strategic  data  planning,  especially  when  integration  of  data 
standards  and  data  values  are  part  of  the  potential  outcome 

Also,  the  customary  Coast  Guard  duty  cycle  will  make  recruitment  of  successor 
data  stewards  and  SMEs  necessary  on  an  ongoing  basis.  Over  time,  this  rotation 
will  place  personnel  throughout  the  Coast  Guard  who  can  take  advantage  of 
shareable  data  resources,  and  who  are  additional  advocates  for  information 
resource  management.  To  anticipate  this  turnover,  the  stewardship  responsibility 
should  be  rotated  among  the  most  knowledgeable  personnel.  Plan  for  transition  by 
appointing  a  deputy  steward  halfway  through  the  scheduled  tour  of  duty. 
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9.5.  Data  Stewardship  Skills  and  Training 


Introduction 


Data 

Stewardship 
Knowledge 
and  Skills 


•  1  ecnnicai  aspect  or  me  iniormation  class,  ana  eacn  prime  wora  in  mat 
class,  and  the  distinctive  meaning  behind  each  prime  word. 

•  Laws,  regulations,  policies,  standards,  and  agreements  that  affect  the 
information  class. 

•  Purpose,  functions,  and  interfaces  of  all  information  systems  that  touch  the 
area(s)  of  responsibility  (legacy  and  standard). 

•  Who  (systems  and  organizations)  is  sharing  information  now,  within  the 
areas  of  stewardship  responsibility. 

•  How  data  of  the  assigned  information  classes  are  shared  with  other 
organizations,  outside  of  CG  fleet  logistics 

•  Which  information  systems  touch  which  data  (where  created,  read, 
updated,  deleted,  and/or  archived) 

•  How  the  larger  organization  (CG)  uses  these  types  of  information;  where  it 
flows. 

•  Use  data  modeling  tool  and  data  dictionary  sufficiently  to  find  information 
about  data  items  and  which  systems  use  them. 

•  Understand  the  principles  and  operation  of  data  administration,  to 
contribute  appropriately  as  a  data  steward. 

•  Understand  and  apply  the  principles  of  data  security  and  data  integrity  in 
review  of  data  element  requests. 


Data  stewardship  is  a  responsibility,  not  a  career.  The  role  of  data  steward  is  the 
link  between  the  user  community  and  the  DA  community.  As  has  been  described 
in  previous  subsections,  the  data  steward's  diligence  and  proficiency  will  make  the 
difference  between  information  systems  that  are  accurate  and  useful,  and  those  that 
don't  quite  fit  the  need. 


The  data  stewardship  role  combines  a  variety  of  skills  and  information,  both  from 
the  steward’s  occupational  specialties  and  from  the  Coast  Guard's  business 
processes  and  the  information  systems  that  support  those  processes. 


Success  of  data  stewards  will  be  improved  by  information  and  skills  in  the 
following  areas: 
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9.6.  Access  to  Tools,  Systems,  and  Information 


The  Data 
Steward's 
Need  to  Know 


To  perform  the  seven  data  stewardship  roles,  each  data  steward  should  have  access 

to: 

•  Enterprise  and  functional  area  strategic  data  plans 

•  The  fleet  logistics  enterprise  business  model,  data  model,  and  data 
encyclopedia 

•  Data  dictionaries  and  data  models  for  non-standard  systems 

•  Data  values  that  are  available  for  sharing  on  standard  systems 

•  Rules  for  determining  data  access,  establishing  data  integrity,  and  ensuring 
data  quality 

•  Identification  of  all  systems  that  use  the  standard  data  elements  within  the 
steward's  assigned  information  class 


Access  to  Recommended  tools  to  perform  data  stewardship  functions  include  the  following: 

Tools  •  A  workstation,  communications,  and  software  with  which  to  display  and  work 

with  the  enterprise  data  model  and  to  submit  queries  for  evaluation  of  data 
element  and  data  model  change  requests 

•  Data  query  tools  and  data  quality  filtering  software,  with  which  to  monitor  the 
quality  of  data  values 

•  Access  to  the  metadata  repository  system 


Access  to  Recommended  system  access  to  perform  data  stewardship  functions  include  the 

Systems  following: 

•  A  guest  user  account  on  all  standard  systems  and  candidate  systems  on  which 
data  element  of  the  steward's  assigned  information  class  are  used 

•  A  user  account  on  the  enterprise  metadata  repository  system 


Participation  Data  stewards  should  participate  in,  and  be  informed  regularly  regarding,  fleet 
in  Data  logistics  strategic  data  planning. 

Planning 

Data  stewards  shall  review  all  design  documents,  including  Functional 
Descriptions,  Concepts  of  Operations,  System  Specifications,  Interface  Design 
Documents,  and  Database  Design  Documents  for  all  new  or  upgraded  information 
systems  that  touch  the  assigned  information  class.  Their  comments  shall  be 
resolved  by  the  enterprise  data  administrator.  The  resolved  comments  shall  be 
incorporated  into  the  Coast  Guard's  review  response. 


Continued  on  next  page 
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9.6. 


Access  to  Tools,  Systems,  and  Information,  Continued 


Participation  Data  stewards  participate  in  process  improvement  working  groups  to  understand 
in  Business  how  various  processes  use  information,  to  advocate  the  use  of  the  standard 
Process  information  resource,  and  to  anticipate  requirements  for  standard  data  definitions. 

Improvement 


Resolving 

Discrepancies 

and 

Disagreement 

s 


In  resolving  disputes  between  SMEs  and  between  data  stewards,  the  enterprise 
data  administrator  will  serve  as  mediator.  If  mediation  does  not  resolve  the 
difference,  the  data  administrator  will  make  the  final  decision. 
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ROLES,  RELATIONSHIPS,  AND  RESPONSIBILITIES 


10.1.  OVERVIEW 


Introduction  This  section  presents  key  roles  and  responsibilities  associated  with  fleet  logistics 
DA.  These  roles  support  data  administration  objectives  for  coordination,  for 
providing  direction  and  oversight,  and  for  data  administration  operations.  The 
objective  of  this  chapter  is  to  provide  an  overview  of  the  contributions  each  role 
makes  to  the  successful  accomplishment  of  fleet  logistics  DA  objectives.  Each 
responsibility  is  described  in  greater  detail  in  another  section  of  this  manual  as 
indicated. 


In  this  Section  The  following  subsections  summarize  the  roles  and  responsibilities  of  the 
individuals  indicated. 


Topic 

Section 

Overview 

10.1 

Key  Roles  and  Their  Relationships 

10.2 

Senior  Management 

10.3 

Fleet  Logistics  Data  Administrator 

10.4 

Metadata  Repository  Administrator 

10.5 

Data  Stewards 

10.6 

Users  of  Data 

10.7 

Supporting  Coast  Guard  Organizations 

10.8 

Developer  or  Maintainer 

10.9 

System  Database  Administrator 

10.10 

Roles,  Relationships,  and  Responsibilities 

10.2.  Key  Roles  and  their  Relationships 


Overview  The  foundation  for  effective  data  administration  is  the  fleet  logistics  enterprise 

data  model,  and  the  quality  of  this  model.  It  provides  the  framework  for 
information  management  policy  and  the  basis  for  the  expenditure  of  resources  to 
implement  that  policy.  This  enterprise  data  model  is  the  principal  information 
management  product  used  by  fleet  logistics  DA.  It  is  described  in  Sections  2  and 
3. 

Fleet  logistics  DA  is  a  central  point  of  contact,  a  resource  for  technical  support  and 
repository  information,  a  coordinator  of  the  data  standardization  process,  and  the 
primary  advocate  for  shareable  data.  Fleet  logistics  DA  is  the  principal 
coordination  point  for  communication  with  fleet  logistics  business  operations 
units,  information  systems  development  teams.  Coast  Guard  organizations  outside 
of  fleet  logistics,  and  organizations  external  to  the  Coast  Guard.  Key  products 
include  plans  for  supporting  migration  from  the  variety  of  non-standardized  legacy 
data  and  systems  environments  to  standard  corporate  logistics  data  and  systems. 

Data  stewards  advocate  technical  accuracy  and  usable  data  standards  for  one  or 
more  information  classes.  Functional  experts  support  the  data  stewards  in 
reviewing  the  data  models  and  data  elements  in  their  area  of  expertise. 

Information  system  developers  and  maintainers  bring  the  enterprise  data  resource 
into  reality  by  analyzing  business  processes,  identifying  standard  data  items,  and 
then  building  and  upgrading  systems  to  create  and  use  standard,  shareable  data  in  a 
reliable  manner.  Shareable  data  is  one  of  the  goals  of  the  Coast  Guard’s 
Information  Resource  Management  (IRM)  strategy  for  cross-functional 
information  systems. 

Users  of  standard  data  benefit  from  the  shareable  information  resource  by  writing 
SQL  queries  and  reports  that  use  data  from  one  or  more  standard  information 
systems. 


Continued  on  next  page 
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10.2.  Key 


Working 

Relation¬ 

ships 


Description 
of  Key  Roles 


Roles  and  their  Relationships,  continued 


Figure  10-1  provides  an  overview  of  the  working  relationships  necessary  for  this 
data  administration  program  to  succeed.  It  shows  the  subsection  references  for  the 
responsibilities  described  in  this  section. 

It  is  not  meant  to  imply  that  there  is  a  corresponding  position  within  the 
organization  of  fleet  logistics  or  any  other  component  of  Coast  Guard  organization 
for  each  role.  Several  roles  may  be  assigned  to  an  individual  or  several  individuals 
may  fulfill  one  role.  It  is  also  possible  that  at  some  point  in  time  an  organization 
may  be  created  to  correspond  to  identified  roles. 


Figure  10-1.  Fleet  Logistics  DA  Program  Organization 

The  following  sections  provide  brief  descriptions  of  each  role.  There  is  also  a 
table  for  each  role.  The  table  summarizes  the  tasks  and  responsibilities,  the 
relationships  with  other  DA  components,  and  principle  products  produced. 

Detailed  discussions  of  the  processes  and  the  roles  required  to  complete  the 
processes  are  found  in  the  preceding  sections  of  this  manual.  Thus,  all  the 
responsibilities  for  a  particular  role  (e.g.,  data  administrator)  have  been  compiled 
for  reference.  Each  responsibility  area  is  described  in  greater  detail  in  Sections  3, 
4, 5,  6, 7, 8, 9  and  11. 
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10.3.  Senior  Management 


Description  CG  senior  management  advises  and  assists  the  program  managers  for  all  fleet 

logistics  programs  and  provides  the  CG  enterprise-wide  perspective  for  making  the 
transition  from  the  current  legacy  system  environment  to  the  standardized, 
integrated  data  environment.  Senior  management,  having  a  CG  enterprise  point  of 
view,  may  serve  as  the  final  authority  for  any  fleet  logistics  issue,  and  can  be 
uniquely  valuable  in  resolving  CG-wide  information  resource  issues. 

CG  Senior  Managers  of  fleet  logistics  business  functions  and  operations  perform  the 
Management  following  activities  to  ensure  efficient  information  sharing. 

Major  Responsibilities _ Scope _ Key  Products 

•  Provides  authority  for  fleet  Fleet  •  Fleet  logistics  DA 

logistics  DA  program  logistics  program 

•  Resolves  issues  requiring  enterprise  •  Issue  resolutions 

senior  level  Coast  Guard  - 

wide  authority 
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10.4.  Data  Administration 


DGSCription  Fleet  logistics  DA  provides  the  lead  role  in  DA  operations.  The  fleet  logistics  DA 
establishes  and  maintains  the  fleet  logistics  data  standards  program  by 
coordinating  the  development,  implementation,  operations,  and  maintenance  of  the 
program,  policies,  procedures,  and  standards.  The  DA  function  refers  to  the 
designated  fleet  logistics  data  administrator  and  others  to  whom  DA  work  is 
delegated. 


DA  Responsibilities  of  the  fleet  logistics  DA  include  providing  fleet  logistics  DA 

Responsibili-  policy,  standards,  and  guidance  to  CG  functional  areas  and  to  information  system 

ties  development  and  maintenance  teams.  The  DA  also  develops  and  maintains  those 

DA  plans  and  strategies  that  are  applicable  to  the  activities  of  the  data  stewards,  to 
the  activities  of  the  development  teams,  and  to  its  own  operational  DA  activities. 

The  DA  performs  the  core  functions  of  reviewing,  approving,  and  disseminating 
metadata  and  information  about  metadata.  The  DA  also  monitors  the  progress  of 
the  DA  program  and  provides  training  regarding  DA  activities.  The  DA  is 
responsible  for  coordinating  with  the  data  repository  administrator  and  with 
information  system  database  administrators  to  assure  effective  management  of  the 
fleet  logistics  enterprise  data  model  and  the  data  element  standardization  program. 


Reference 


Detailed  descriptions  of  the  data  administrator's  responsibilities  are  found  in  the 
following  sections: 

•  Section  3.  Support  Development  and  Integration  of  Data  Models, 

•  Section  4.  Standardize  Data  Elements, 

•  Section  5.  Share  Data  by  Mapping  and  Migration, 

•  Section  7.  Control  Changes  to  Metadata,  and 

•  Section  8.  Ensure  Data  Quality. 


DA  Responsi-  Under  the  direction  of  the  data  administration  manager 

bilities  _ 


Major  Responsibilities 

Scope 

Key  Products 

•  Provides  fleet  logistics  DA  policy 
and  procedures 

•  Develops  fleet  logistics  DA 
strategy 

•  Coordinates  with  other  Coast 
Guard  offices  on  matters 
concerning  fleet  logistics  data 
management 

•  Supports  all  fleet  logistics 
development  efforts 

Fleet 
logistics  - 
wide 

•  DA  procedures 

•  DA  standards 

•  Integrated  corporate 
logistic  data  model 

•  Standardized  fleet  logistics 
data  elements 

•  Data  quality  and  security 
procedures 

•  Fleet  logistics  DA  training 
program 

Continued  on  next  page 
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10.4.  Data  Administration,  Continued 


Major  Responsibilities 

Scope 

Key  Products 

•  Develops  and  ensures  the 
integrity  of  the  fleet  logistics  data 
architecture 

•  Reviews  conceptual  and  logical 
data  models 

•  Coordinates  with  data  modeling 
analysts  to  ensure  compatibility 
of  data  definitions 

•  Reports  data  definition 
discrepancies 

•  Tracks  resolution  of  data 
discrepancies 

•  Accepts  data  models  for 
inclusion  in  the  repository 

•  Maintains  control  of  revisions  to 
data  models 

•  Provides  guidance  and  instruction 
for  data  standards  and 
administration 

•  Reviews  design  documents 

•  Reviews  application  models 

•  Coordinates  development  and 
integration  of  models  into  the 
fleet  logistics  enterprise  data 
model 

•  Improves  data  model 
development  and  integration 
process 

•  The  following  activities  are 
detailed  in  Section  4 

•  Controls  and  manages  data  and 
metadata 

•  Reviews  data  element  change 
requests 

•  Approves  or  disapproves  data 
element  change  requests 

•  Coordinates  resolution  of 
technical  and  functional  review 
conflicts 

•  Notifies  change  request  submitter 
of  approval  or  disapproval 

•  Updates  "where-used"  references 
to  information  systems  for  data 
elements 

•  Fleet  logistics  data  and 
metadata  repository 

•  Standards  for  data  models, 
methods,  and  tools 

Continued  on  next  page 
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10.4.  Data  Administration,  Continued 


DA  Responsi-bilities  (continued) 


•  Archives  existing  standard  data 
elements 

•  Reinstates  archived  data  elements 

•  Releases  to  users  changes  to 
metadata 

The  following  activities  are  detailed 
in  Section  5. 

•  Coordinates  definition  and  use  of 
data  structures  among 
organizational  components 

•  Supports  and  facilitates  system 
upgrade  and  data  conversion 

•  Reviews  metadata  mapping  plans 
and  other  documents 

•  Assists  developers  in  compiling 
legacy  data  element  inventory 

•  Maintains  legacy  data  element 
inventory 

The  following  activities  are  detailed 
in  Section  7. 

•  Reviews  metadata  change 
requests 

•  Approves  metadata  change 
requests 

•  Releases  metadata  change 
requests 

The  following  activities  are  detailed 
in  Section  8. 

•  Defines  data  quality  and  security 
procedures 

•  Trains  developers  in  standards 
and  use  of  the  repository 

•  Answers  questions  and  solves 
problems 

•  Accepts  and  registers  standard 
systems 

•  Assigns  change  requests  to  data 
stewards 


Continued  on  next  page 


10-7 


Roles,  Relationships,  and  Responsibilities 

10.4.  Data  Administration,  Continued 


DA  Responsi-bilities  (continued) 


•  Resolves  disagreements  between 
data  analysts,  data  stewards,  and 
others 

•  Accepts  and  registers  new  and 
upgraded  systems 

•  Incorporates  data  models  into  the 
fleet  logistics  enterprise  data 
model 

•  Notifies  the  user  community  of 
newly  registered  or  upgraded 
systems 

•  Reviews,  evaluates,  and  approves 
or  rejects  requests  to  modify  DA 
standards 

•  Reviews,  evaluates,  and  approves 
or  rejects  requests  for  exemptions 
from  DA  standards 

•  Conducts  risk  assessments 

•  Reviews  data  synchronization 

•  Compiles  and  publishes  a 
dictionary  for  metadata  terms 

Other  responsibilities 

•  Manages  fleet  logistics  data 
model 

•  Develops  standard  fleet  logistics 
data  elements  and  other  data 
products 

•  Establishes,  operates,  and 
maintains  the  repository 

•  Establishes  and  maintains 
standards  for  data  models, 
methods,  and  tools 

•  Provides  fleet  logistics  DA 
procedures  and  training 

•  Develops  action  plans _ 
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10.5. 


Metadata  Repository  Administrator 


Description  The  metadata  repository  administrator  manages  the  repository  containing  all  DA 
products.  A  complete  discussion  of  metadata  repository  operation  is  the  subject  of 
Section  6.  However,  at  this  writing,  the  platform  and  tools  for  the  fleet  logistics 
metadata  repository  have  not  been  selected.  Responsibilities  are  identified  below, 
but  specific  operational  details  will  be  provided  by  the  developer  of  the  repository 
system. 


Metadata  Responsibilities  of  the  administrator  of  the  fleet  logistics  metadata  repository 

Repository  include  the  following. 

Administra¬ 
tor  Responsi¬ 
bilities 


Major  ResponsibUities 

Scope 

Key  Products 

•  Assists  the  fleet  logistics  data 

Fleet 

•  Updated  metadata 

administrator  in  utilizing 

logistics  - 

repository 

repository  resources  required  for 

wide 

•  Metadata  repository 

data  element  standardization 
efforts 

•  Facilitates  the  receipt,  delivery, 
and  maintenance  of  the 
documentation  and  other 
deliverables  identifying  fleet 
logistics  configuration  items 

•  Extracts  metadata  objects  from 
repository 

•  Imports  models  from 
development  tool  format  to  the 

DA  repository  format 

security  and  quality 

Continued  on  next  page 
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10.5.  Metadata  Repository  Administrator,  continued 


Metadata  Repository  Administra-tor  Responsi-bilities  (continued) 


•  Extracts  sets  of  repository  objects 
for  data  modeling  analysts,  data 
stewards,  and  others  with  a  need 
for  them 

•  Generates  lower  level  data 
models  from  the  repository 

•  Links  repository  objects  to 
corresponding  objects  in  other 
data  models 

•  Assigns  ownership  of  repository 
objects 

•  Registers  changes  to  metadata 

•  Identifies  impact  of  metadata 
changes  on  other  models 

•  Propagates  changes  to  metadata 

•  Implements  approved  metadata 
changes 

•  Incorporates  accepted  metadata 
into  repository 

•  Assures  integrity  of  the 
repository  tool 
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10.6.  Data  Stewards 


Description  Data  stewards  manage  an  assigned  set  of  metadata  on  behalf  of  the  Coast  Guard. 

A  data  steward  captures  or  creates  metadata  in  the  process  of  carrying  out  business 
functions  and  oversees  the  definition  of  data  required  for  the  business.  Data 
stewardship  responsibilities  are  explained  in  detail  in  Section  9.  In  addition,  data 
stewards  should  understand  the  metadata  development  and  review  process 
described  in  Sections  3  and  4,  and  the  data  quality  and  security  criteria  described 
in  Section  8. 

Data  stewards  keep  the  standard  data  definitions  complete  and  accurate.  By 
representing  the  community  that  uses  and  is  responsible  for  each  information  class, 
data  stewards  keep  the  standard  data  definitions  current.  Each  data  steward  is 
responsible  for  one  or  more  categories  of  information  in  the  enterprise  data  model. 
These  categories  are  referred  to  as  information  classes. 


Data  Steward  Data  stewards  are  the  link  between  the  information  systems  community  and  the 
Responsi-  various  user  and  mission  area  communities.  Active  data  stewardship  ensures  that 
biiities  data  standards  are  set  properly,  for  long-term  use  by  many  systems,  and  ensures 

that  the  interests  of  data  users  are  represented.  Stewardship  responsibilities 
include  the  following: 


Data  For  additional  detailed  information  about  data  stewards,  their  role,  and  the  entire 

Stewardship  data  stewardship  program,  refer  to  Section  9:  Implement  Data  Stewardship. 
Program 


Continued  on  next  page 
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10.6.  Data  Stewards,  continued 


Major  ResponsibQities 

Scope 

Key  Products 

•  Understand  how  data  is  used 
across  the  Coast  Guard  enterprise 

•  Determine  requirements  for 
standard  (enterprise)  data  and 
participate  in  strategic  data 
planning  activities 

•  Provide  data  standardization 
leadership  and  support 

•  Recruit  and  coordinate  the 
participation  of  subject  matter 
experts 

•  Review  change  requests  for 
candidate  standard  data  elements 

•  Assure  that  candidate  data 
elements  will  meet  functional 
data  requirements 

•  Assess  impact  of  change  requests 
on  appropriate  data  models 

•  Coordinate  with  other  data 
stewards  regarding  requested 
changes 

•  Recommend  approval  or 
rejection  to  the  data 
administrator 

•  Identify  and  assign  experts  to 
review  metadata 

•  Provide  for  and  verify  data 
quality 

•  Represent  users  of  data  within 
the  information  class 

•  Review  and  approve  data  models 

•  Approve  standard  data  elements 

•  Approve  entity  attribute  names 
and  definitions 

•  Establish  data  quality  standards 
for  data  within  their  authority 

•  Grant  access  to  data  within  their 
authority 

•  Maintain  tables  of  business  codes 

•  Provide  the  data  administrator 
with  "data  steward  approved" 
metadata 

Assigned 
subject  area, 
collection  of 
entities,  or 
collection  of 
entity 
attributes 

•  Foundation  of  information, 
skills,  and  contacts 

•  Identify  opportunities  for 
data  sharing,  improving 
data  quality,  improving  the 
consistency  of  data  access 
rules,  and  improving 
business  processes 

•  Identification  of  subject 
matter  experts  within  the 
supporting  Coast  Guard 
organizations 

•  Approved  data  models 

•  Approved  entity  attribute 
names  and  definitions 

•  Approved  standard  data 
elements 

•  Standards  for  assessing  the 
quality  of  data 

•  Identification  of  data  of  less 
than  acceptable  quality 
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10.7. 


Users  of  Data 


Description  "Users  of  data"  refers  to  those  individuals  and  organizations  that  are  responsible 
for  performing  any  of  the  business  functions  being  supported  by  the  information 
systems.  In  addition  to  use  of  specific  information  systems,  some  users  require 
aggregated  data  from  several  systems.  Users  who  generate  aggregated  reports, 
create  ad-hoc  SQL  queries,  or  audit  multiple  systems  require  familiarity  with  the 
structure  and  naming  of  standard  data  items.  The  reliability  of  aggregated  data 
depends  directly  on  the  consistency  of  data  element  definitions  and  attributes 
across  systems,  and  the  care  with  which  these  definitions  and  attributes  are 
implemented. 

Users  who  enter  or  modify  data  are  responsible  for  the  quality  of  the  data  values 
they  create.  Users  are  also  responsible  for  generating  business  process 
improvements  (including  better  use  of  standard  information)  and  information 
system  requirements,  and  create  applications,  reports,  and  queries  as  needed. 
Users  ultimately  judge  the  quality  of  the  data  provided,  and  define  the 
requirements  for  additional  data  or  changes  in  the  representation  or  form  of  the 
data. 


Users  of  Data 


Major  Responsibflities 

Scope 

Key  Products 

•  Plan  strategic  use  of  data 

•  Identify  data  quality  issues  and 
problems 

•  Identify  additional  data 
requirements 

•  Ensure  proper  use,  modification, 
and  creation  of  data  values 

•  When  accepting  new  or  upgraded 
information  systems,  ensure  that 
data  meets  fleet  logistics  data 
sharing  standard 

Business 

function 

•  Identification  of  issues  and 
problems 

•  Identified  data 
requirements 
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10.8.  Coast  Guard  Organizations 


Description  The  role  of  the  constituent  fleet  logistics  organizations  is  key  to  understanding  the 
relationship  of  the  data  models,  entities,  and  data  elements  to  the  requirements  of 
the  business  functions.  The  mission  area  organizations  are  units  within  the  Coast 
Guard  that  provide  subject  matter  expertise  to  the  fleet  logistics  data  administrator 
to  facilitate  the  resolution  of  standardization  issues  that  arise.  They  support  data 
stewards  by  providing  technical  information  and  reviewing  data  element 
definitions  within  their  area  of  expertise. 


Coast  Guard  CG  organizations  who  perform  fleet  logistics  functions  or  use  fleet  logistics 
Organiza-  information  provide  resources  to  validate  models;  validate  name,  definition,  and 
tions  attributes  of  data  elements;  and  assure  the  security  and  quality  of  data  for  the 

business  functions.  They  assist  the  data  stewards  in  keeping  the  standard  data 
definitions  complete,  accurate,  and  useful  over  time.  Being  part  of  a  community 
that  uses  and  is  responsible  for  information,  they  can  keep  data  definitions  current 
and  effective.  The  success  of  the  program  depends  on  the  following  kinds  of 
support  from  constituent  organizations. 


Major  ResponsibUities 

Scope 

Key  Products 

•  Consult  with  fleet  logistics  Data 
Administrator 

•  Provide  subject  matter  expertise 
to  resolve  standardization  issues 

•  Assure  that  the  supporting 
organization's  requirements  are 
adequately  reflected  within  fleet 
logistics  data  administration 

•  Consult  to  analysts  modeling 
business  processes,  modeling 
data,  and  defining  data  elements 

•  Validate  data  models  of  the 
business  function 

•  Validate  standardized  data 
elements 

•  Validate  quality  of  data  for  a 
business  function 

•  Assure  security  for  data  of  a 
business  function 

Subject  area 

•  Resolutions  to  issues 
within  subject  area 

•  Definition  of  subject  area 
DA  requirements 

•  Validated  data  models 

•  Validated  standardized  data 
elements 

•  Validated  standards  for 
data  quality 

•  Validated  levels  for  data 
security 
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10.9.  System  Developer  or  Maintainer 


Description  Data  models  are  developed  at  various  times,  under  various  initiatives,  and  within 
various  CG  organizations.  CG  information  resource  management  (IRM)  policy 
demonstrates  the  need  for  integrated,  cross-functional  information  systems. 
Isolated,  single-mission  systems  are  contrary  to  CG  IRM  policy.  As  information 
systems  are  upgraded,  their  respective  data  structures  should  be  revised  to  bring 
them  into  consistency  with  the  fleet  logistics  (or  wider  enterprise)  metadata 
standard.  The  advantages  to  CG  mission  areas  include  reduction  in  software 
development  and  maintenance  costs,  more  efficient  acquisition  and  use  of 
information,  integration  of  more  sources  of  information  for  decision  support,  and 
the  availability  of  a  wider  base  of  technical  support. 

Coordination  and  integration  of  data  must  be  an  inherent  part  of  each  system 
development  and  maintenance  activity,  at  the  same  level  as  integration  of 
functions,  equipment,  and  software.  Therefore  each  system  development  or 
maintenance  manager  should  assign  the  responsibility  to  an  individual  to  perform 
the  role  of  data  model  coordinator.  (This  is  a  role,  not  necessarily  a  position 
within  the  organization.) 

The  terms  "developer  or  maintainer"  and  "development  team"  are  used  frequently 
throughout  this  manual.  They  refer  to  those  performing  the  various  functions  for 
developing,  modifying,  and/or  supporting  information  systems.  The  development 
team  data  modeler(s)  is  (are)  the  principal  producer(s)  and  user(s)  of  data 
administration  products.  In  this  section,  therefore,  the  role  is  named  "data 
modeling  analyst." 

Data  modeling  is  an  integral  component  of  business  analysis.  For  every  fleet 
logistics  initiative  involving  business  analysis,  a  data  modeling  effort  will  be 
performed  by  data  modeling  analysts.  Data  modeling  analysts  support  information 
system  changes  or  new  development  needed  to  achieve  the  objectives  of  functional 
process  improvements,  initiatives  to  migrate  existing  systems,  and  short-term 
initiatives.  They  analyze  and  evaluate  requirements  to  incorporate  standardized 
data  element  definitions  and  formats  in  the  migration  system  or  process 
improvement  development,  and  effect  the  changes  once  approved.  Data  modeling 
analysts  also  support  the  re-engineering  of  systems  to  be  migrated  by  separating 
the  data  from  application  source  code  and  procedures  in  order  to  move  toward  data 
independence.  They  are  responsible  for  coordinating  any  changes  into  the  systems 
with  fleet  logistics  Data  Administration  and  with  the  business  function  managers. 


Continued  on  next  page 
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10.9.  System  Developer  or  Maintainor,  Continued 


Data  Model  The  data  model  coordinator  is  the  designated  point  of  contact  within  the  developer 
Coordinator  organization  for  ensuring  metadata  standards. 


Major  ResponsibQities 

Scope 

Key  Products 

•  Facilitates  the  integration  of 
various  components  of  fleet 
logistics  data  modeling  and  data 
element  standardization  activities 

•  Assists  the  data  modeling  teams 
in  planning  and  executing 
integration  activities 

•  Conducts  integration  exercises 
and  analyses 

•  Facilitates  resolution  of 
integration  issues  among 
modeling  teams,  working  groups, 
or  data  stewards  and  custodians 

•  Prepares  metadata  for  joint  user- 
developer  technical  reviews 

•  Coordinates  maintenance  of 
results  of  integration  efforts  with 
the  fleet  logistics  metadata 
repository 

Program, 
project,  or 
information 
system 

•  Advice  and  counsel  for 
data  model  integration 

•  Consistent  data  model 
using  fleet  logistics 
standard  data  model  as  the 
foundation 

•  Identify  truly  unique  data 
items  to  be  submitted  as 
candidate  data  elements 

•  Preliminary  logical  data 
model 

•  Attributed  data  model 

•  Data  sharing  and  interface 
requirements 

•  DBDD  and  IDD, 
preliminary  and  final 
versions 

•  Metadata  change  requests 
and  new  data  element 
requests 

Change  Each  system  development  and  maintenance  organization  has  a  change  control  or 

Control  configuration  management  responsibility.  Included  in  that  responsibility  is  the 

necessity  to  keep  the  application’s  approved  logical  data  model  concurrent  with  the 
physical  database  design. 


Continued  on  next  page 
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10.9.  System  Developer  or  Maintainer,  continued 


Data  Modeling  Data  modeling  analysts  can  be  part  of  a  developer,  maintainer,  or  user 
Analyst  organization.  This  role  can  include  systems  analysts,  information  systems 

engineers,  and  functional  experts  trained  in  process  analysis  and  data  modeling. 
The  intent  is  to  address  those  who  translate  their  understanding  of  information 
requirements  into  a  logical  data  model,  and  who  reconcile  the  application’s 
information  requirements  with  standard  metadata. 


Major  Responsibilities 

Scope 

Key  Products 

•  Analyze  subsystem  data 
requirements 

•  Populate  the  application’s  CASE 
tool  with  standard  metadata  from 
the  fleet  logistics  repository 

•  Define  information  requirements 
in  a  standardized  format,  using 
fleet  logistics  standard  metadata 
as  a  starting  point 

•  Develop  conceptual  data  models 

•  Develop  logical  data  models 

•  Develop  standard  names  and 
definitions  for  data  elements 

•  Request  changes  to  data  models 
where  an  expansion  or 
refinement  to  standard  metadata 
is  indicated 

•  Develop  requests  for  additional 
standardized  data  elements 

•  Develop  requests  for  changes  to 
standardized  data  elements 

•  Identify  and  define  data  element 
attributes 

•  Re-engineer  data  for  systems  to 
be  migrated 

•  Define  legacy  data  element 
inventories 

•  Define  legacy  data  element  maps 

•  Identify  migration  data 

•  Coordinate  and  integrate  the 
standard  definitions  with  those  of 
other  subsystems 

•  Recommend  improvements  to 
data  standards  and  data 
administration  processes 

Subsystem¬ 

wide 

•  Definitions  of  data 
requirements 

•  Entity-relationship  models 

•  Logical  data  models 

•  Physical  data  models 

•  Requests  for  standardized 
data  definitions  and  names 
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10.10.  Database  Administrators 


Description  Database  administrators  for  standard  systems  and  for  enterprise-wide  reference 
data  maintain  their  respective  subject  area  or  application  databases,  in  alignment 
with  standard  metadata.  Database  administrators  maintain  the  security  and 
integrity  of  the  data  values  that  comprise  the  shared  information  resource. 

Database  administrators  have  the  critical  responsibility  for  release  as  shareable 
data  only  those  values  that  comply  with  fleet  logistics  data  standards,  and  to  accept 
(import,  download)  data  values  only  from  registered  standard  information  systems. 


Database  Responsibilities  of  database  administrators  of  registered  fleet  logistics  standard 

Administra-  systems  include  the  following. 

tors 


Major  Responsibilities 

Scope 

Key  Products 

•  Enforces  the  policies,  standards, 
and  procedures  set  by  the  Data 
Administrator 

•  Contributes  to  the  establishment 
of  the  physical  data  architectures 

•  Provides  technical  support  for  the 
databases 

•  Coordinates  database 
development,  maintenance,  and 
operations  activities 

•  Manages  the  information 
repository,  software,  and 
databases  for  the  fleet  logistics 
data  administrator 

•  Provides  input  on  fleet  logistics 
data  management  policies  and 
procedures 

Assigned 

information 

system(s) 

•  Updated  data  repository 

•  Data  repository  security 
and  quality 
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SECTION  1 1 

DATA  LIFE  CYCLE  METHODOLOGIES 


11.1.  Overview 


Purpose 


This  section  describes  the  metadata  that  is  required  at  each  phase  of  information 
system  development.  It  describes  various  methodologies  and  tools  that  help  the 
designer  to  discover  and  describe  the  information  that  is  then  used  in  the 
application  and  shared  across  the  enterprise. 

Metadata  and  data  values  have  a  life  cycle  different  from  that  of  an  information 
system.  Data  tends  to  remain  constant  while  business  processes,  organizations, 
and  information  systems  change  over  time.  That  is,  people  and  organizations 
improve  how  they  deal  with  information,  but  the  kinds  of  information  within  a 
given  mission  area  remain  remarkably  stable  over  time.  Describing  the 
information  accurately  and  competently,  and  in  a  manner  that  facilitates  sharing  of 
data  is  therefore  central  to  the  design  of  a  business  process  and  for  the  information 
systems  that  support  the  business  process. 


In  this  Section  This  section  contains  the  following  subsections: 


Topic 

Section 

Overview 

11.1 

Life  Cycle  of  Standard  Metadata 

11.2 

System  Life  Cycle  Metadata  Requirements 

11.3 

Metadata  Documentation 

11.4 

Information  Systems  Engineering  and  Management  Tools 

11.5 

Working  Relationships 

11.6 

Data  Life  Cycle  Methodologies 


11.2.  Life  Cycle  of  Standard  Metadata 


Purpose  Metadata  has  its  own  life  cycle  of  proposal,  review,  acceptance  into  the  enterprise 

standard,  and  retirement.  This  subsection  summarizes  the  metadata  life  cycle  as  it 
applies  to  all  fleet  logistics  standard  metadata.  For  detail  regarding  the  specific 
life  cycle  for  data  models,  data  entities,  and  standard  terms,  refer  to  the  appropriate 
subsections. 


Metadata  Life  Information  tends  to  endure,  both  in  data  types  and  data  values,  longer  than 
Cycle  specific  information  systems,  business  processes,  or  organizations.  The  processes 

for  management  of  metadata,  that  is,  management  of  the  definitions  and 
characteristics  of  data,  follows  this  series  of  stages.  Figure  11-1  shows  the 
relationship  between  the  system  development  cycle  (described  later  in  this 
section),  the  data  element  life  cycle  (described  in  Section  4),  and  the  standard 
metadata  life  cycle.  The  figure  highlights  data  elements  because  requests  to 
change  data  element  detail  are  the  most  frequent  metadata  transaction. 


Continued  on  next  page 
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1 1.2.  Life  Cycle  of  Standard  Metadata,  Continued 


Identification  This  process  involves  enterprise  data  planning  and  data  use  planning.  The  sub¬ 
processes  include  classification  of  subject  business  data  and  identification  of  stable 
data  entities. 

User  organizations,  information  systems  managers,  data  administrators,  and  senior 
management  participate  in  strategic  data  planning.  Strategic  data  planning 
includes  a  range  of  activities,  from  providing  information  support  to  new  business 
processes,  to  planning  the  sharing  of  data  with  other  organizations,  to  refining  the 
scope  of  information  classes  and  high-level  entities.  Enterprise  information 
sharing  and  data  administration  initiatives  are  two  of  the  outcomes  of  strategic  data 
planning.  This  is  the  activity  that  will  change  the  scope  of  the  enterprise  as  data 
sharing  becomes  more  central  to  CG  operations. 


Standardize-  This  process  yields  shareable  processes,  data  entities,  and  data  element 
tion  characteristics  and  definitions  that  are  unambiguous  across  the  enterprise. 

Development  teams,  process  improvement  teams,  and  data  stewards  perform 
process/activity  and  data  modeling  to  obtain  accurate  and  widely  usable  data  entity 
and  element  descriptions. 

Data  element  descriptions  (for  new  DEs  or  for  modification  to  existing  standard 
DEs)  that  are  in  review  are  candidate  data  elements. 


Acquisition  This  stage  defines  data  sources,  uses,  integrity  rules,  and  quality  and  security 

requirements.  The  acquisition  stage  is  the  part  of  the  data  life  cycle  that  spans  the 
information  system  development  phases.  It  is  also  the  phase  in  which  single  points 
of  data  collection  (i.e.,  data  administration)  are  defined. 

The  fleet  logistics  data  administrator  must  work  with  acquisition  staff  to  ensure 
that  sufficient  metadata-specific  contractual  language  and  data  item  description 
(DID)  detail  is  included  in  each  procurement.  Data  administration  activities  to 
build  and  standardize  an  enterprise  metadata  repository,  and  to  populate  it  with 
valid,  useful  standard  entities  and  data  elements,  is  the  central  activity  of  this 
phase.  To  ensure  the  validity  of  the  standard  entities  and  data  elements,  data 
stewards  and  subject  matter  experts  perform  the  activities  detailed  in  Section  9. 


Continued  on  next  page 
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11.2.  Life  Cycle  of  Standard  Metadata,  continued 


Maintenance  This  stage  keeps  data  current,  timely,  and  accurate  based  on  quality  and  security 
and  configuration  management  procedures.  Data  recovery  and  restoration  are 
provided  for  data  values  during  this  life-cycle  phase.  Metadata  is  refined  through 
the  metadata  change  request  process. 

Metadata  maintenance  includes  advancing  standard  data  elements  to  the 
"modified"  and  "archived"  stages,  as  described  in  Section  4. 


Archive  Data  and  metadata  are  retired  from  day-to-day  use,  but  are  kept  somewhat 

available  for  later  reference.  Data  archiving  means  stable  storage  of  values. 
Metadata  archiving  means  retirement  of  names,  definitions,  characteristics,  or  key 
terms  that  are  no  longer  in  active  use. 


Disposal  This  final  stage  occurs  with  the  decommissioning  and  destruction  of  data  that  is  no 

longer  needed  or  required  by  law,  order,  regulation,  or  potential  use.  For  fleet 
logistics  data,  this  process  applies  to  data  values  and  metadata. 

Retention  of  data  values  is  determined  by  the  Federal  law  (44  U.S.C.  2901) 
Records  Management,  and  implemented  by  the  National  Archives  and  Records 
Administration  (NARA).  COMDTINST  5212.16,  Transferring  Records  to 
Federal  Records  Centers  (FRC)  implements  this  policy  for  the  Coast  Guard. 
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11.3.  System  Life  Cycle  Metadata  Requirements 


Purpose  Each  new  and  upgraded  information  system  requires  attention  to  data  standards  to 

ensure  a  high-quality  shared  data  resource  for  fleet  logistics.  Regardless  of  the 
methodology  used  to  develop  a  specific  information  system,  each  information 
system  evolves  through  a  series  of  stages,  from  initial  concept  to  retirement.  To 
provide  for  valid,  complete,  and  sharable  data,  the  appropriate  metadata  must  be 
developed  for  each  of  a  system's  development  stages. 

This  subsection  identifies  a  set  of  generic  development  stages  and  shows  how  to 
include  the  appropriate  levels  and  types  of  metadata  as  part  of  each  stage. 
Deliverable  documentation  is  recommended  that  will  provide  a  focal  point  for 
metadata  standards  design  and  compliance  reviews. 


Overview  The  various  Government  and  commercial  life  cycle  methodologies  each  have  a 

particular  emphasis.  Most  of  these  provide  for  tailoring  of  processes  and 
documents  to  fit  the  scope  of  the  application. 

The  two  documentation  styles  that  have  been  used  for  many  Government 
information  system  procurements  are  DOD-STD-2167A  and  DOD-STD-7935A. 
At  this  writing,  MIL-STD-498  is  superseding  both.  While  all  three  of  these 
standards  have  their  roots  in  defense  systems,  they  provide  a  structure  and  proven 
management  approach  that  has  proven  useful  to  many  agencies.  Coast  Guard 
systems  are  likely  to  utilize  tailored  versions  of  these  styles,  with  the  addition  of 
organization-specific  program  management  tools. 


Continued  on  next  page 
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11.3.  System  Life  Cycle  Metadata  Requirements,  Continued 


System  Life 
Cycle  Stages 


The  following  table  provides  a  set  of  general  information  system  development 
phases,  and  shows  how  these  phases  apply  to  the  standard  Major  Automated 
Information  System  Review  Council  (MAISRC)  milestones,  to  two  recently-used 
Government  system  development  standards,  and  to  the  standard  that  recently 
superseded  the  other  two. 


General 

Phase 

MAISRC 

Mile¬ 

stone: 

DOD-STD-2167A 

DOD-STD-7935A 

MIL-STD-498  * 

Planning 

0 

Project  planning 
and  oversight; 
Establishing  a 
development 
environment 

Requirements 

Analysis 

1 

System 

Requirements 

Analysis 

Design  Phase: 
Definition 

System 

requirements 

analysis 

System 

Design 

2 

System  Design 
Functional 

Baseline 

Design  Phase: 
Design 

System  design; 
Software 
requirements 
analysis 

Detailed 

Design 

HW/SW  Rqts 
Analysis 
Preliminary 
HW/SW  Design; 
Detailed  Design 
Allocated 

Baseline 

AIS& 

Telecomm. 

Technical 

Adequacy 

Validated  and 
Approved 

Software  design 

Development 

3 

Coding  and  CSU 
Testing; 

Hardware 

Fabrication 

Development 

Software 
implementation 
and  unit  testing 

Integration 
and  Testing 

CSC  Integration 
&  Testing; 

CSCI  Testing; 
HWCI  Testing; 
System 

Integration  & 
Testing 

Product  Baseline 

Development: 

Integration 

Development: 

Test 

Unit  integration 
and  testing 

CSCI  quality, 
testing 

CSCI/HWCI 
integration  and 
testing 

Continued  on  next  page 
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11.3.  System  Life  Cycle  Metadata  Requirements,  continued 


System  Life  Cycle  Stages  (continued) 


General 

Phase 

MAISRC 

Mile¬ 

stone: 

DOD-STD-2167A 

DOD-STD-7935A 

MIL-STD-498  * 

Acceptance 

4 

Physical  Config. 
Audit;  Formal 
Qualification 

Review;  Testing 
&  Evaluation 
(SAT) 

Development: 

Evaluation 

System  qualification 
testing 

Operations 

Production 

Deployment 

Deployment 

Phase 

Operations 

Phase 

Preparing  for 
software  use; 

Preparing  for 
software  transition 

Retirement 

5 

Transition 

*  MIL-STD-498  describes  "major  activities,  which  may  overlap,  may  be  applied  iteratively,  may 
be  applied  differently  to  different  elements  of  software,  and  need  not  be  performed  in  the  order 
listed."  It  requires  that  the  developer's  software  development  process  be  described  in  the  software 
development  plan.  When  following  MIL-STD-498,  metadata  requirements  and  deliverables 
should  therefore  be  keyed  to  the  activities  rather  than  to  the  milestone/phase  sequence.  This 
difference  does  not  relieve  the  developer  of  design  responsibilities  or  deliverables;  it  merely 
permits  tailoring  of  the  process  sequence  to  accommodate  a  wider  range  of  methodologies. 

The  general  development  phases  in  this  table  will  be  used  in  this  document  to 
indicate  the  phase  in  which  specific  data  administration  activities  must  take  place. 


Planning  What  it  is:  Planning  starts  with  recognition  of  the  need  for  the  new  or  enhanced 

system,  and  continues  throughout  the  project.  As  a  development  phase.  Planning 

typically  requires  the  following: 

•  Demonstration  of  the  need,  and  the  priority  of  meeting  the  need 

•  Demonstration  of  the  concept  and  methods  that  are  proposed  to  meet  the  need 

•  Citing  the  fit  of  the  system  into  the  organization's  plans  and  standards 

•  Identifying  scope,  program  responsibilities,  and  development  environment. 

What  to  do:  Effective  data  administration  starts  early  in  the  planning  phase.  The 

following  data-related  activities  should  be  part  of  the  planning  phase: 

•  Ensure  that  sufficient  contractual  language  is  included  in  the  procurement  to 
support  effective  data  administration,  and  which  will  result  in  development  or 
upgrade  of  an  information  system  that  meets  fleet  logistics  metadata  standards 

•  Verify  the  flow  of  information  among  business  processes 

•  Identify  current  and  future  inter-organization  information  sharing  requirements 

•  Review  standards  and  regulations  that  prescribe  how  information  will  be  kept, 
shared,  and  protected 

•  Review  the  business  process  model  for  conformance  to  CG  standard  business 
processes  and  support  of  standard  metadata  (data  stewards) 

•  Review  the  organization's  strategic  data  plan,  and  implement  the  strategy  by 

applying  its  information  sharing  approach  and  metadata  standards. _ 

Continued  on  next  page 
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11.3.  System  Life  Cycle  Metadata  Requirements,  continued 


Requirements  What  it  is:  This  phase  starts  with  defining  the  problem(s)  and  describing  the 
&  Analysis  current  and  desired  (to-be)  business  processes,  information  flow,  and  automation 
support.  This  phase  can  consist  of  a  formal  system  analysis  or  a  less  formal 
requirements  survey,  depending  on  the  nature  of  the  system,  the  environment,  and 
the  organization.  For  a  large,  multi-phase  system,  the  full  requirements  set  may 
not  be  complete  until  the  final  phase.  The  important  benefit  of  this  phase  is  for  all 
stakeholders  to  agree  on  what  is  needed  and  exactly  what  is  to  be  done.  Revisiting 
the  general  system  requirements  and  goals  later  on  in  the  project  can  be  expensive. 

What  to  do:  Data  administration  should  review  the  business  process  model  or 
equivalent  analytical  product  from  the  previous  phase..  From  this  description,  one 
can  identify  the  kinds  of  information  the  system  will  process,  what  data  should  be 
shared,  and  what  data  will  be  shared  with  which  outside  systems.  If  the  business 
process  model  has  sufficient  detail,  the  data  administrator  and  the  appropriate  data 
stewards  can  assess  the  data  synchronization  requirements,  detect  potential  risk  to 
data  quality,  and  identify  data  that  will  require  restricted  access  or  enhanced 
protection.  During  this  phase  the  developer  should  integrate  the  current  enterprise 
logical  data  model  into  the  selected  CASE  (or  other  system  design)  tool,  so  that  all 
design  work  is  based  on  standard  metadata.  The  developer  creates  and  DA  reviews 
a  high-level  logical  data  model  (usually  represented  by  one  or  more  entity 
relationship  diagrams). 


System  What  it  is:  System  design  starts  with  approval  of  the  requirements  and  the  solution 

Design  concept.  The  developer  designs  the  system  to  meet  the  requirements  that  were 

approved  in  the  previous  phase.  Design  descriptions  and  interface  documents  are 
developed.  Part  of  this  design  process  is  the  logical  data  model,  which  will  shape 
the  contents  of  the  database  design  document  (DBDD),  interface  design 
document(s)  (IDD),  and  later,  the  physical  design  of  the  database  and/or  object 
definitions.  This  phase  includes  system-wide  design  decisions  about  the  system's 
behavioral  design,  interfaces,  and  operations.  These  decisions  are  documented  in 
the  system/subsystem  design  description  (SSDD),  which  should  include  evidence 
of  commitment  to  use  of  standard  metadata  and  sharing  of  valid  data  values. 

What  to  do:  The  developer  uses  the  approved  logical  data  model  to  create  and 
submit  an  attributed  data  model.  At  this  time  the  developer  should  identify  any 
attributes  (data  elements)  for  which  standard  data  elements  cannot  be  matched. 
Data  administration  reviews  the  attributed  data  model,  DBDD,  IDD,  and  SSDD. 


Continued  on  next  page 
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11.3.  System  Life  Cycle  Metadata  Requirements,  continued 


Detailed 

Design  What  it  is:  During  detailed  design,  process  and  data  models  are  developed  to  a 

consistent  level  of  detail.  Software  design  should  include  the  business  rules, 
validity  checks,  synchronization,  and  security  protection  that  is  indicated  in  the 
data  element  definitions. 

What  to  do:  Review  software  design  descriptions  (SDD)  for  compliance  with  the 
business  rules,  validity  checks,  synchronization,  and  security  protection  that  is 
indicated  in  the  data  element  definitions.  Review  the  detailed  version  of  the 
DBDD  and  IDD(s).  Ensure  that  test  plans  provide  for  using  standard  test  data  that 
is  provided  by  DA. 


Development  What  it  is:  Development  includes  coding  and  unit  testing,  and  installation  of 

equipment.  If  the  design  is  complete  and  valid,  the  development  phase  should  not 
uncover  unexpected  data  standards  discrepancies.  Any  discrepancies  that  are 
found  must  be  corrected  with  change  requests. 

What  to  do:  Provide  to  the  development  team  samples  of  test  data  for  all  standard 
data  elements  used  by  the  system.  Samples  should  include  values  that  represent 
the  full  range  of  the  data  element's  domain  and  that  demonstrate  important  points 
of  the  data  element's  definition.  By  providing  these  samples,  DA  improves  the 
chances  that  the  system  will  treat  data  values  in  accordance  with  the  standard,  and 
will  avoid  unnecessary  corrections  and  re-testing  later.  Evaluate  and  respond  to 
change  requests  from  the  development  team  as  quickly  as  possible,  and  with 
constructive  suggestions  regarding  how  to  handle  the  discrepancy  that  prompted 
the  request. 


Continued  on  next  page 
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11.3.  System  Life  Cycle  Metadata  Requirements,  Continued 


integration  What  it  is:  As  major  pieces  of  the  system  are  completed,  they  are  tested,  first 

and  Testing  individually  and  then  in  combination  with  other  pieces.  The  tests  should  include 

demonstration  of  the  system's  ability  to  support  the  business  rules,  validity  checks, 
synchronization,  and  security  protection  that  is  indicated  in  the  data  element 
definitions.  DA  should  provide  a  test  data  set  that  includes  the  range  of  data 
values  for  each  data  element,  as  well  as  tests  of  data  quality,  security,  and 
synchronization. 

What  to  do:  Integration  starts  as  elements  of  the  system  come  out  of  development 
and  are  tested  together.  Integration  often  uncovers  detail-level  problems,  which 
may  require  adjustment  of  the  data  model  or  an  element  definition. 

For  each  system,  testing  must  include  sharing  of  standard  data.  For  most  systems, 
data  sharing  is  two-way:  the  system  reads  standard  data  from  the  network,  and 
other  systems  collect  data  from  the  new  system  (routinely  or  in  ad-hoc  queries). 

The  tested  system  forms  the  product  baseline.  The  product  baseline  is  the  as-built 
version  (usually  numbered  1 .0)  against  which  future  changes  are  described  in 
Version  Description  Documents  (VDD). 


Acceptance  What  it  is:  The  Coast  Guard  reviews  the  test  reports  and  approves  transition  of  the 
system  from  development  to  deployment. 

What  to  do:  Acceptance  is  a  relatively  short  phase,  where  the  CG  transfers 
program  management  responsibility  from  the  developer  to  the  user  organization. 

The  main  data  administration  issue  with  acceptance  is  reliable  data  sharing.  By 
this  point,  all  metadata  and  deliverable  documents  should  have  been  submitted  and 
any  discrepancies  resolved.  As  part  of  acceptance,  DA  registers  the  new  standard 
system  for  data  sharing. 


Operations  What  it  is:  Ongoing  operation  of  the  system,  with  occasional  upgrades,  after 

deployment  and  before  retirement.  The  operations  phase  extends  from  first  system 
deployment  to  last  system  retirement. 

What  to  do:  Ensure  that  the  system  is  creating  valid  data  values  for  shareable  data 
elements. 


Continued  on  next  page 
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System  Life  Cycle  Metadata  Requirements,  continued 


Retirement  What  it  is:  Replacing  the  system  with  its  successor,  and  ensuring  a  smooth 

transition  to  the  new  system.  Retirement  may  also  include  archiving  of  data  that 
was  not  migrated  to  the  new  system,  or  as  a  snapshot  of  all  data  on  the  retiring 
system.  Retirement  starts  with  the  decision  to  replace  the  system,  and  ends  when 
the  transition,  archiving,  or  termination  of  the  last  operational  copy  of  the  system. 

What  to  do:  Successful  transition  of  any  system  is  a  complex  and  demanding  task, 
demanding  attention  to  detail.  Each  transition  situation  is  different.  DA  must 
identify  the  data  to  be  migrated  to  the  successor  system,  ensure  archiving  of  the 
current  system's  data,  and  identify  the  measures  necessary  to  protect  the  data 
resource  during  transition. 
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11.4  Metadata-Related  Documentation 


Purpose 


Metadata  in 

Requirements 

Documents 


This  section  describes  the  deliverable  documents  that  are  associated  with  most 
system  development  efforts.  It  cites  the  parts  of  these  documents  that  concern  data 
administration  and  recommends  review  points  at  the  appropriate  development 
phase. 


The  most  effective  development  phase  in  which  to  incorporate  standard  data  is  the 
initial  concept  development  phase.  If  the  decision  to  standardize  data  is  made  after 
the  design  is  well  along,  then  redesign  and  rethinking  will  be  required.  If  the 
decision  to  standardize  data  occurs  even  later  in  the  development  cycle,  then  more 
extensive  rework  will  be  required. 


General  Phase 

MIL-STD-498 

Activity 

Data  Admin. 
Activities 

Metadata  Deliverables 

Planning 

Project 
planning  and 
oversight 
Establishing  a 
development 
environment 

Strategic  data 
planning 

Business  process, 
model,  rules; 
Contribute  to 
operation,  concept, 

FD,  SOD,  SDP. 

Strategic  data  plan. 

Cite  data  sharing  & 
standards  in  Operational 
Concept  Document 

Requirements 

Analysis 

Requirements 

analysis 

Logical  data  model, 
identification  of 
entities,  E-R 
diagram, 

Populate  CASE  tool 
with  standard  data 
dictionary; 

Risk  analysis  (data 
synchronization, 
quality,  &  security) 

E-R  diagram,  showing 
use  of  standard  entities 
and  elements,  and 
potential  areas  for  unique 
or  modified  DEs; 

Definition  of  all  entities; 
Data  CRUD 
requirements  in  SRS; 
data  sharing  rqts  in  IRS 

System 

Design 

System  design 

Attributed  data 
model; 

Define  data 
elements. 

Attributed  data  model; 
requests  for  new  or 
modified  data  elements 

Continued  on  next  page 
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11.4  Metadata- Related  Documentation,  continued 


Metadata  in  Requirements  Documents  (continued) 


Detailed 

Design 

Software 
implementation 
and  unit  testing 

Physical  database 
design  per  approved 
model; 

Interface  design 
doc. 

DBDD,  showing 
implementation  of 
approved  metadata  into 
physical  design.  IDDw/ 
use  of  std.  data  defs. 

Development 

Software 
implementation 
and  unit  testing 

Provide  a  test  set  of 
data  values  (Test 

Data)  that  meet  std. 

Code  and  SDFs  show 
adherence  to  std.  data 
element  defs,  names, 
validation,  synch.,  etc. 

Integration 
and  Testing 

Unit  integration 
and  testing 

CSCI  testing 
CSCFHWCI 
int.  &  test 

Audit  data  values 
per  standard 
Deployment 
planning; 

Data  qual.  planning 

Test  reports  show 
successful  creation, 
reading,  update,  and 
deletion  of  data  values, 
relying  on  std  definitions. 

Acceptance 

System 

qualification 

testing 

Validate  data  per 
standard;  validate 
data  sharing  w/ 
other  standard 
systems. 

All  data  values  match  std. 
metadata.  Successful 
inbound  and  outbound 

SQL  queries  using  std. 
defs  &  names. 

Maintenance  Plan 

Operations 

Preparing  for 
software  use 
Preparing  for 
sys.  transition 

Monitor  data 
quality,  success  in 
data  sharing. 

System  Administration 
Manual;  training 
materials;  Version 
Description  Docs 

Retirement 

I 

Transition  data  to 
successor  or  archive 

Decision  Paper; 

Transition  Plan 

DA 

Responsibil¬ 
ities  for 
Documenta¬ 
tion 


It  is  the  responsibility  of  DA  and  the  program  office  to  ensure  that  strategic  data 
planning  is  part  of  the  initial  planning  process,  that  each  procurement  provides  for 
sufficient  data  standardization  work  and  metadata-related  deliverables,  that 
sufficient  data  standardization  planning  is  part  of  each  requirements  and  design 
document,  and  that  standardization  and  transparency  of  data  is  tested  before 
acceptance.  DA  will  participate  in  the  review  these  documents  as  submitted,  and 
use  them  for  analysis  and  evaluation  of  the  system's  metadata  and  potential  for  data 
sharing. 


It  is  the  responsibility  of  the  fleet  logistics  data  administrator  to  ensure  that 
sufficient  data-related  documentation  (and/or  equivalent  electronic  deliverables) 
remains  on  the  Contract  Data  Requirements  List  (CDRL)  for  each  information 
system  acquisition.  Subsequently,  the  fleet  logistics  data  administrator  must 
ensure  that  subsections  related  to  data  sharing,  data  exchange  using  well-defined 
interfaces,  conformance  to  metadata  standards,  and  commitment  to  qualification  as 
a  standard  system  are  not  tailored  or  negotiated-out  of  the  deliverables. 


Continued  on  next  page 
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11.4  Metadata-Related  Documentation,  Continued 


Basis  for 
Document 
Titles  and 
Content 


The  names  and  content  assumptions  for  the  following  documents  are  taken  from 
MIL-STD-498.  At  this  writing,  this  standard  has  superseded  DOD-STD-2167A 
and  DOD-STD-7935A  as  the  most  frequently  used  life  cycle  and  documentation 
standard  for  government  information  system  acquisition.  Systems  that  follow 
different  standards  will  have  slightly  different  allocation  of  activities  by 
development  phase  and  may  use  different  names  for  the  deliverable  documents. 

Any  complete  development  standard  will  address  the  requirements  for  this  basic 
information.  The  assigned  data  administrator  will  have  to  examine  the  standard 
and  determine  where  the  equivalent  data-related  information  is  provided,  and 
review  those  deliverables  accordingly. 


Documents  Figure  1 1-2  shows  the  relationship  between  system  development  phases  and  the 
by  associated  deliverable  documents  that  should  be  reviewed  by  DA. 

Development 

Phase 


Phase  Metadata  Product  Related  Documentation  Product(s) 


Requirements  Analysis 


Figure  11-2.  Deliverable  Documents  by  Development  Phase 


Continued  on  next  page 
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11.4  Metadata-Related  Documentation,  continued 


Operational 

Concept 

Description 

(OCD) 


The  OCD  is  the  product  of  initial  requirements  analysis.  It  describes  the  current 
situation  and  proposes  an  improved  set  of  processes,  work  flow,  and  information 
system  support.  Other  titles  for  top-level  concept  documents  are  System  Overview 
Document  (SOD),  conceptual  architecture,  and  Functional  Description  (FD). 


DA  should  review  the  OCD  for  commitment  to  data  sharing  and  qualification  as  a 
standard  system.  This  document  may  contain  business  process  information  that 
permits  early  evaluation  of  potential  data  quality,  synchronization,  and  security 
risks.  The  general  business  processes  and  subject  areas  will  indicate  which  data 
stewards  should  receive  copies  of  the  OCD  for  advance  notice  and  comment. 


System  or 
Subsystem 
Specification 
(SSS) 


The  SSS  is  the  product  of  system  design.  It  describes  in  detail  each  function 
(behavior)  of  the  proposed  system,  along  with  supporting  services,  processes,  and 
interfaces.  The  industrial  equivalent  is  the  functional  specification.  An  additional 
level  of  design  detail  may  be  provided  later  (detailed  design  phase)  in  a 
System/Subsystem  Design  Description  (SSDD).  Completing  the  detailed  design 
requires  reference  to  the  business  process  model  and  logical  data  model. 


DA  should  review  the  SSS  for  use  of  fleet  logistics  standard  processes  and 
standard  data  (standards  and  values).  As  part  of  this  review,  DA  should  evaluate 
the  system  for  data  quality,  synchronization,  and  security  risks.  In  formal 
development  methods,  the  SSS  is  the  subject  of  the  System  Design  Review.  DA 
should  participate  in  the  detailed  review  and  in  the  acceptance  decision  process. 


System 

Requirements 

Document 


(SRS) 


The  SRS  is  the  product  of  detailed  design.  A  larger  project  with  multiple 
subsystems  may  break  out  requirements  into  separate  SRS  documents.  The  SRS 
describes  precisely  how  the  system  will  perform  each  of  the  functions  described  in 
the  SSS.  From  a  data  standards  point  of  view,  the  SRS  cannot  be  completed 
without  reference  to  the  attributed  data  model. 


DA  should  review  the  SRS  for  use  of  standard  metadata  wherever  data  input, 
output,  processing,  or  exchange  are  addressed.  Since  the  attributed  data  model 
must  be  approved  before  the  SRS  can  be  completed,  the  review  should  include 
traceability  of  data  elements  and  entities  to  the  approved  data  model. 


Continued  on  next  page 


11-15 


Data  Life  Cycle  Methodologies 

11.4  Metadata-Related  Documentation,  Continued 


Database  The  DBDD  is  completed  as  part  of  detailed  design.  It  describes  each  file,  field, 

Definition  and  relationship  in  the  physical  database  (or  the  equivalent  object  definitions  in  an 

(Design)  object-oriented  system).  If  a  design  team  is  not  planning  to  deliver  a  logical  data 

Docunrient  model  in  the  requirements  analysis  phase,  a  preliminary  version  of  this  document 

(DBDD)  can  permit  review  of  the  use  of  standard  (and  new/revised)  entities. 

DA  review  should  trace  each  DBDD  field  (or  object)  definition  to  the 
corresponding  entity  and  attribute  in  the  approved  attributed  data  model.  Data 
stewards  representing  the  related  information  classes  should  participate  in  this 
review. 


Interface  IDDs  are  prepared  during  detailed  design,  one  for  each  major  interface.  For  a 

Definition  standard  system,  the  main  IDD  should  describe  the  system's  interface  to  the  fleet 

Document  logistics  enterprise  information  resource. 

(IDD) 

DA  review  of  IDDs  is  especially  important  because  each  IDD  is  an  instance  of  data 
sharing.  The  IDD  description  of  exchanged  data  should  be  in  terms  of  standard 
metadata,  or  at  least  mapped  to  standard  data  elements.  Data  stewards 
representing  the  related  information  classes  should  participate  in  this  review. 


Test  Test  plans  are  prepared  during  system  design.  For  acceptance,  the  developer  must 

Documents  demonstrate  the  successful  operation  of  each  function  and  interface.  From  a  data 

administration  point  of  view,  the  planned  tests  should  demonstrate  the  ability  of 

the  software  to: 

•  Handle  the  full  range  of  values  permitted  by  the  standard  data  element's 
domain 

•  Enforce  the  business  rules  and  definitions  that  lead  to  creation  or  update  of 
data  values 

•  Perform  error  checking  to  ensure  the  quality  of  data  values 

•  Ensure  proper  synchronization  of  data  value  updates 

•  Allow  read  or  write  access  only  to  those  users  and/or  processes  that  are 
authorized 

•  Create  instances  (records  or  objects)  that  conform  to  the  corresponding 
standard  data  element  definition  and  attributes. 

The  DA  tests  should  include  data  portability,  inquiry  from  outside  using  standard 

names,  outside  reference  from  inside  using  standard  names,  and  ad-hoc  query. 

Continued  on  next  page 
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11.4  Metadata-Related  Documentation,  Continued 


User  Manuals  User  manuals  are  developed  during  system  development,  and  validated  near  the 
end  of  the  system  integration  and  testing  phase.  One  of  the  primary  purposes  of 
enterprise-wide  data  sharing  is  to  provide  users  with  a  wider  range  of  information 
resources.  Application  software  often  uses  enterprise-wide  reference  tables,  or 
shares  specific  transactions  with  other  applications.  This  level  of  automated  data 
sharing  should  be  represented  to  the  mission-area  user,  so  that  the  user  can  benefit 
from  the  available  information. 

DA  should  review  user  manuals  for  proper  representation  of  the  fleet  logistics 
enterprise  information  resource,  for  emphasis  on  data  quality  for  users  who  create 
or  update  data  values,  and  for  accurate  instructions  for  use  of  (access  to)  enterprise 
data  values.  Because  user  understanding  and  participation  are  critical  to  the 
success  of  the  enterprise  information  resource,  DA  review  of  user  manuals  is 
important  to  the  success  of  the  program. 


Training  Training  materials  typically  are  prepared  at  the  end  of  the  development  cycle  and 

Materials  validated  during  integration  and  testing,  and  are  intended  to  be  ready  for  system 

deployment.  Training  materials  may  address  different  audiences  and  technical 
levels,  such  as  system  administration,  technical  support,  functional  end  users,  and 
managers  of  user  organizations.  For  a  standard  system,  training  should  include 
instruction  in  effective  use  of  the  wider  data  resource. 

Because  training  materials  tend  to  combine  instruction  in  the  business  processes 
along  with  how  to  use  the  system,  the  appropriate  data  stewards  and  subject  matter 
experts  are  ideal  reviewers. 
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11.5.  Information  Systems  Engineering  and  Management 
Tools 


Purpose  The  purpose  of  this  subsection  is  to  show  the  use  of  typical  tools  in  support  of  an 

enterprise-wide  data  administration  program.  The  purpose  of  the  feature  sets  and 
examples  is  not  to  endorse  specific  methodologies  or  products,  but  rather  to 
represent  a  minimum  feature  set  in  any  suite  of  methodologies  and  tools  that  will 
enable  a  development  team  to  participate  fully  in  the  DA  program. 


Development  The  following  table  suggests  tools  that  a  development  team  may  find  useful  to 
Tools  support  the  work  of  one  or  more  life  cycle  phases: 


General 

Development 

Phase 

MAISRC 

Milestone 

Data-Related  Tasks 

Typical  Tools 

Planning 

0,1 

Strategic  data  planning, 
business  process  (activity) 
modeling,  prototyping 

Prototyping,  JAD,  Activity 
or  Process  Modeling,  project 
planning,  budgeting 

Requirements 

Analysis 

Logical  data  modeling 

Data  Encyclopedia;  CASE 

System 

Design 

2 

Attributed  data  modeling, 
data  element  definition; 
Reconciling  app.  data  rqts. 
w/  enterprise  standard 

Data  Modeling 

Detailed 

Design 

Database  design,  interface 
design 

Model  Integration 

Development 

3 

Incorporating  business  rules, 
data  quality  criteria,  data 
integrity  checks,  and  access 
protection  into  the  software 

Code  Generation,  Version 
Control,  Code  Library 

Integration 
and  Testing 

Use  of  DA-supplied  test 
data;  verifying  transparent 
data  sharing 

Automated  Testing,  Data 
Mapping 

Acceptance 

4 

Review  of  data-related  tests 

Operations 

Sampling  of  enterprise  data, 
review  of  data  quality; 
analysis  of  data  quality  and 
integrity  problems 

Technical  Support,  Data 
Validation,  Generation  and 
Tracking  of  Change 

Requests 

Retirement 

5 

Ensure  effective  transition, 
data  migration,  data 
archiving. 

Archive  Index 

The  general  development  phases  in  this  table  indicate  the  phase  in  which  specific 
data  administration  and  standards  activities  must  occur.  _ 


Continued  on  next  page 
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11.5.  Information  Systems  Engineering  and  Management 
Tools,  Continued 


Data  An  enterprise-wide  metadata  repository  supports  strategic  data  planning,  functional 

Dictionary  process  improvement,  migration  initiatives,  functional  model  integration,  and  data 
standardization.  The  data  dictionary  function  of  the  repository  provides  the 
following  capabilities: 

•  Provide  a  point  for  integration  and  standardization  of  enterprise-wide  metadata 

•  Consolidate  the  organization's  knowledge  about  information  assets 

•  Provide  reports  and  ad-hoc  queries  to  describe  how  and  where  Coast  Guard 
information  assets  are  used,  especially  identifying  systems  where  specific 
standard  metadata  is  used. 

•  Facilitate  communication  among  developers,  data  administrators,  and  data 
stewards 

•  Facilitate  data  asset  configuration  control,  and  track  the  state  of  each  standard 
process,  data  entity,  element,  and  definition  throughout  its  life  cycle. 

•  Provide  interfaces  to  other  repositories,  such  as  the  Defense  Data  Repository 
System  (DDRS),  the  Defense  Logistics  Encyclopedia  (DLE),  and  the  Army 
Data  Encyclopedia  System  (ADSS). 

The  Coast  Guard  Data  Administration  Data  Dictionary  System  (DADS)  is 
documented  in  the  DADS  User’s  Guide.  DADS  functions  available  to  a  fleet 
logistics  DA  user  are  summarized  in  Section  12. 


Continued  on  next  page 
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11.5.  Information  Systems  Engineering  and  Management 
TooiS,  Continued 


Process 

Modeling 

Tools 


This  type  of  tool: 

•  Identifies  the  work  of  activities  in  transforming  inputs  to  outputs 

•  Shows  activity  relationships  and  the  nature  of  their  interaction 

•  Supports  several  levels  of  activity  decomposition 

•  Models  and  rolls-up  the  cost  of  activities 

To  be  useful  for  developing  standard  metadata,  a  process  modeling  tool  should: 

•  Adhere  to  rules  of  activity  modeling,  and  automatically  perform  consistency 
and  integrity  checking  on  the  model 

•  Balance  the  levels  of  decomposition,  and  be  able  to  subset  and  merge  activity 
models 

•  Provide  means  for  analyzing  and  noting  timeliness  and  synchronization  of 
processes  and  updating  of  data  values 

•  Provide  means  for  analyzing  external  and  internal  data  interfaces,  as  a 
preliminary  means  of  assessing  data  sharing  requirements 

•  Allow  for  validation  and  testing  on  discrete  models  and  on  integrated  baseline 
models,  to  assess  the  effect  of  changes 

•  Provide  an  interface  to  the  DA  standard  repository,  so  that  standard  activity 
definitions  can  be  used 

•  Support  the  standard  range  of  analysis  and  information  system  engineering 
methodologies 

•  Enhance  ease  of  use  and  productivity,  and  should  not  require  extensive 
training  beyond  the  standard  analysis  methodology 


Process  or  activity  modeling  tools  manage  detail  to  enable  analysts  to  describe  the 
application's  functional  processes.  The  tool  provides  a  convenient  means  to 
simplify  and  streamline  the  descriptions,  to  permit  several  views  of  each  process, 
and  to  assess  the  value  of  an  activity  to  the  process. 


Continued  on  next  page 
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11.5.  Information  Systems  Engineering  and  Management 
TooiS,  Continued 


Data  Modeling  Data  modeling  tools  are  used  to  evaluate  and  design  functional  entities  so  that 
Tools  essential  data  assets  are  provided  for  all  users  without  redundancy,  in  a  system  that 

provides  effective  and  economical  storage  of  data. 

To  be  an  effective  analysis  and  design  tool,  an  acceptable  data  modeling  tool 

should: 

•  Identify  the  entities  (things  or  objects)  which  are  used  by  each  function  or 
activity,  and  to  describe  each  in  sufficient  detail  to  meet  the  requirements  set 
forth  in  the  Data  Modeling  and  Quality  sections. 

•  Identify  processes  by  associating  entities  and  defining  business  rules. 

•  Support  several  levels  of  entity  attribution,  identify  key  attributes,  and 
normalize  entities  to  the  third  normal  form. 

•  Verify  the  data  model  against  the  activity  model  to  reconcile  the  application's 
processes  and  data  (all  processes  use,  create,  or  change  information;  all  data 
touches  at  least  one  process). 

•  Subset  and  merge  data  models. 

•  Provide  an  interface  (transfer  format)  to  the  DA  enterprise  data  model. 

•  Provide  reference  and  selection  of  standard  process  and  entity  definitions  from 
the  DA  enterprise  data  model. 

•  Support  the  information  systems  engineering  methodology  of  the  development 
team,  with  current  industry  standard  feature  set  and  rigor. 


Data  Mapping  Data  mapping  tools  are  used  to  link  data  elements  of  legacy  systems  to  standard 
Tools  data  elements,  thereby  building  a  data  dictionary  and  permitting  data  sharing  with 

legacy  systems. 


Version  Version  control  is  as  important  for  metadata  as  it  is  for  specifications,  code. 

Control  Tools  documentation,  or  any  other  component  of  an  information  system.  The  larger 
CASE  tools  include  version  control  as  part  of  their  feature  set.  For  a  smaller  or 
less  formal  system,  a  separate  version  control  system,  such  as  the  UNIX  Source 
Code  Control  System  (or  its  enhanced  commercial  successors)  can  provide  storage 
of  each  change,  access  to  any  change  level,  major  and  minor  releases,  and  check 
out/check  in  services. 


Continued  on  next  page 
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11.5.  Information  Systems  Engineering  and  Management 
TooiS,  Continued 


Automated  Automated  test  tools  provide  a  thorough  means  for  verifying  a  system's  response  to 
Test  Tools  an  infinite  combination  of  commands,  data,  and  conditions.  The  results  can  point 
to  errors  in  the  application  software,  communications,  equipment,  data  structures, 
or  configuration.  Automated  testing  works  by  building  a  test  script,  which 
launches  the  desired  combination  of  commands  and  simulates  a  workload.  The 
fast  and  thorough  generation  of  transactions  provides  a  more  consistent  test  than 
most  humans  have  the  patience  and  attention  span  to  conduct.  The  tool  also 
collects  responses  and  detects  all  discrepancies  from  expected  responses.  The 
evaluators  of  the  system's  functions  are  likely  to  specify  the  automated  test  system. 
The  DA  interest  in  this  type  of  tool  is  to  ensure  that  the  selected  tool  handles  a 
wide  variety  of  data  values  and  attributes. 

DA  should  supply  a  set  of  test  data  values  that  includes,  for  each  standard  data 
element  used  by  the  system,  examples  of  the  range  of  the  domain  and  that  tests  the 
business  rules,  quality  criteria,  and  security  protection  that  are  defined  for  the 
respective  data  element. 
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Purpose 


Key 

Interactions 


The  purpose  of  this  subsection  is  to  describe  the  functional  relationships  between 
data  administration  at  the  developer  and  DA  levels,  to  other  areas  of  the 
information  system  development  and  management  community. 


The  nature  of  the  work  changes  from  phase  to  phase  in  any  development  task.  The 
interactions  that  are  critical  to  development  of  valid,  standard  metadata  and 
portable  and  usable  data  values  begin  in  the  system  planning  and  concept 
development  phases.  The  following  table  suggests  which  inter-team  interactions 
deserve  management  attention  and  facilitation  at  each  phase  of  system 
development. 


General  Phase 

MAISRC 

Milestone: 

Purpose  of  Interaction 

Parties  whose 
Cooperation  is  Needed 

Planning 

0,1 

Initiate  strategic  data 
planning 

Program  management 

Requirements 

Analysis 

1 

Ensure  utilization  of 
standard  tools  &  defs. 

Application  analysis 
staff 

System 

Design 

2 

Ensure  utilization  of 
standard  tools  &  defs. 

Application  analysis 
staff 

Detailed 

Design 

2 

Ensure  utilization  of 
standard  tools  &  defs. 

Application  analysis 
staff 

Development 

3 

Ensure  physical  design 
matches  the  approved 
logical  design 

Development  staff, 
program  management 

Integration 
and  Testing 

3 

Ensure  data  integrity, 
security,  synchronization, 
and  portability  is  tested 

Testing  staff 

Acceptance 

4 

Ensure  data  stds  compliance 
is  part  of  acceptance  criteria 

Program  management 

Operations 

4+ 

Support  data  validity, 
integrity,  and  security 

System  operations  & 
technical  support 

Retirement 

5 

Ensure  proper  migration  of 
data 

Successor  program 
management 

In  addition,  at  each  phase  after  the  functional  baseline  is  established,  DA  must 
coordinate  with  the  program's  configuration  management  staff  and  with  the 
appropriate  configuration  manager  to  ensure  that  version  numbers  are  assigned 
consistently,  and  that  all  metadata  changes  are  tracked. 


Detail  regarding  the  working  relationships  of  the  various  stakeholders  in  the 
enterprise  information  resource  are  provided  in  Section  10,  Roles, 
Responsibilities,  and  Relationships. 
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SECTION  12 


COAST  GUARD  DATA  ADMINISTRATION  DICTIONARY 

SYSTEM  (DADS) 


Introduction  The  Coast  Guard  Data  Administration  Dictionary  System  (DADS)  is  the  Coast 
Guard  repository  tool  currently  in  production.  The  target  design  for  DADS  is  a 
highly  structured  Data  Dictionary/Directory  (DD/DS)  containing  information 
about  the  Coast  Guard’s  significant  data  processing  and  information  resource 
management  (IRM)  processing  resources.  Testing  of  the  data  element  dictionary  is 
now  complete  and  the  system  is  in  initial  operational  mode.  The  data  element 
standardization  process,  as  described  in  COMDTINST  5230.42  in  coordination 
with  this  the  process  described  in  this  manual,  is  the  major  focus  of  the  DADS 
effort. 

Data  modelers  should  also  reference  the  DOD  Defense  Data  Repository  System 
(DDRS),  as  well  as  any  local  Coast  Guard  dictionaries  for  development  efforts. 
The  DDRS  and  other  such  dictionaries  are  discussed  in  Section  12.2. 


In  this  Section  This  section  contains  the  following  topics: 


DADS 


12.1  Data  Administration  Dictionary  System 


introduction  DADS  is  in  an  initial  operational  mode.  For  full  discussion  of  the  functionality  of 

DADS,  contact  the  CG  Data  Administration  Staff,  G-TTC-3,  for  a  copy  of  the 

User’s  Manual.  In  general,  the  following  functionality  exists  within  DADS: 

•  Access  Control  -  Including  user  accounts  and  privileges  assignments  to  screens 
and  fields 

•  System  Maintenance  -  Including  problem  prevention,  problem  reporting,  and 
change  requests. 

•  Manipulating  Data  Models  and  Data  Elements  -  Including  creating,  modifying, 
submitting,  and  querying  data  models  and  data  elements. 


Fleet  When  developing  or  updating  a  fleet  logistics  data  model,  DADS  may  provide 

Logistics  Use  useful  names  and  definitions  for  data  elements  that  are  not  yet  part  of  fleet 

of  DADS  logistics  standard  metadata.  Fleet  logistics  developers  may  inquire  from  DADS 

directly,  but  must  submit  requests  for  changed  and  new  data  elements  through  fleet 
logistics  DA. 
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DADS 


12.2  Other  Automated  Dictionary  Systems 


introduction  In  addition  to  DADS,  refer  to  the  pertinent  dictionary  systems  during  data 
modeling  and  data  element  development. 

DDRS  In  particular,  because  many  of  the  fleet  logistics  data  administration  standards  are 

based  on  DOD  data  standards,  the  Department  of  Defense  Repository  System 
(DDRS)  is  probably  one  of  the  best  information  sources  for  identifying  data  entity 
and  data  element  requirements  for  system  development.  For  more  information  on 
accessing  the  DDRS,  contact  the  Defense  Information  Systems  Agency  (DISA). 


Application  In  addition  to  the  DDRS,  presently  there  are  system  development  efforts  within  the 
Data  Coast  Guard  that  could  also  help  in  the  development  of  other  systems.  For 

Dictionaries  example,  the  Supply  Center  Computer  Replacement  (SCCR)  system  is  the  primary 

Coast  Guard  development  effort  that  was  referenced  while  researching  and 
developing  this  manual.  The  SCCR  data  dictionary  runs  on  Oracle  CASE. 

For  more  information  on  accessing  an  application-specific  data  dictionary  system, 
contact  the  Information  Resource  Management  division  of  the  proponent 
organization. 
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APPENDIX  A 

INFORMATION  SYSTEMS  CONCEPTS  FOR  DA 


Purpose 


A.1.  Data 


Guiding 
Principles  for 
Integrated  Data 
Management 


This  appendix  provides  a  summary  of  the  more  technical  information  systems 
engineering  and  data  administration  concepts  used  in  this  manual.  For  additional 
information  regarding  these  topics,  refer  to  the  documents  cited  in  Section  1. 


Architecture  Concepts 


The  fleet  logistics  DA  program  will  adhere  to  the  guiding  principles  developed  by 
logistics  architectural  planning  and  the  concept  of  operations: 

•  Data  is  a  shared  resource  that  should  be  defined  and  structured 
independent  of  applications. 

•  Data  should  be  treated  as  a  primary  and  vital  resource  independent  of 
current  technology  and  systems. 

•  Standard  tools  and  facilities  should  be  used  throughout  an  organization  to 
manage  data. 

•  Users  should  be  given  the  tools  to  specify  and  retrieve  the  information  and 
reports  directly  from  a  common,  integrated  data  environment. 

•  Development  and  support  methods  need  to  change  to  bring  about  a  new 
integrated  environment. 

•  Management  needs  to  be  involved  in  the  organizations  data  management 
strategy. 


Continued  on  next  page 


Information  System  Concepts  for  DA 


A.1.  Data  Architecture  Concepts,  Continued 


Introduction  This  section  introduces  several  concepts  crucial  to  satisfy  the  mission,  goals,  and 
objectives  of  the  fleet  logistics  data  administration: 

•  Fleet  logistics  architectures  and  data  models 

•  Fleet  logistics  development  environment  and  data  administration 
infrastructure 

•  Metadata  repository  and  its  metadata  model 


Fleet  Development  of  fleet  logistics  information  systems  (applications)  follows 

Logistics  development  methodologies  based  on  industry  standard  information  engineering 

Architectures  practices.  According  to  these  methodologies,  applications  are  developed  based  on 
five  architectures.  These  architectures  are  defined  for  Work  Process,  Data, 
Applications,  Organization  and  Roles,  and  Technical  Infrastructure.  Data 
administration  is  concerned  with  three  of  those  architectures:  Work  Process 
Architecture,  Data  Architecture,  and  Applications  Architecture. 


L  Work  Process  Architecture 

defines  logistics  business  processes 

2.  Data  Architecture 

provides  an  organized  data  model  that  satisfies  the 
information  requirements  of  work  processes  and 
organizations 

3.  Applications  Architecture 

identifies  and  defines  the  software  systems  that 
support  the  logistics  work  processes 

Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.1.  Data  Architecture  Concepts,  continued 


Data  Fleet  logistics  data  architecture  is  critical  to  the  ability  of  logistics  business  to 

Architecture  share  data  across  functions,  organizations,  locations,  and  applications.  To  achieve 
an  enterprise  point  of  view,  the  fleet  logistics  data  architecture  must  be  completed 
to  the  logical  level  of  detail,  represented  as  an  entity  relationship  (E-R)  diagram 
with  entity  and  relationship  definitions.  A  valid  enterprise  view  will  provide  a 
model  that  will  be  useful  across  all  fleet  logistics  business  processes  and 
applications.  This  enterprise  view  will  enable  effective  data  integration  between 
multiple  development  projects  (applications  or  sets  of  applications). 

The  fleet  logistics  data  architecture  serves  several  purposes: 

•  It  provides  common  information  concepts  (entities  and  their  attributes)  for 
integrating  data  definitions  across  boundaries  imposed  by  different 
organizations,  functions,  locations,  and  information  systems. 

•  It  provides  an  adequate  level  of  detail  to  effectively  design  physical 
databases.  For  example,  a  well-constructed  data  model  primarily 
identifies  entities  which  exist  in  the  "business"  processes  of  an 
organization  independent  of  the  way  the  processes  are  performed. 

•  It  provides  definition  of  relationships  among  entities  and  corresponding 
databases  and  thus  facilitates  both  control  of  data  integrity/consistency  as 
well  as  it  facilitates  access  to  data  via  these  relationships. 

•  It  precludes  repeated  re-definition  of  logical  entities,  data  elements,  and 
relationships  because  the  enterprise  view  supports  all  fleet  logistics 
functions. 

•  It  ensures  reusable,  transparently  shareable  data  for  all  standard  systems 
and  for  use  across  systems. 

•  It  reduces  the  costs  of  independent  systems  analysis  and  data  modeling  for 
each  new  and  upgraded  application  systems. 

•  It  provides  a  planning  basis  for  migrating  data  from  legacy  systems  to 
standard  systems. 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.1.  Data 


Architectural 

Framework 


Levels  and 
Scope  of  Data 
Models 


Architecture  Concepts,  Continued 


Data  architectures  are  represented  in  a  framework  having  three  levels.  They  are 
conceptual,  logical,  and  physical  levels. 

Fleet  logistics  conceptual  data  architecture  is  based  on  the  following  concepts: 

•  Subject  Area 

•  Information  Class 

Fleet  logistics  logical  data  architecture  is  based  on  the  following  concepts: 

•  Logical  Data  Model 

•  Entity 

•  Relationship 

•  Attribute  and  Standard  Data  Element 

Fleet  logistics  physical  data  architecture  is  based  on  the  following  concepts: 

•  Physical  Data  Model 

•  Physical  File  /  Relational  Table 

•  Physical  Data  Field  /  Table  Column 


As  shown  in  the  following  diagram,  data  models  may  be  defined  on  different  levels 
of  detail  (logical  entity-relationship  diagram,  logical  attributed  data  model,  physical 
model). 

Data  models  can  also  be  defined  for  different  scopes  of  interest,  for  example: 

•  Functional  (e.g.  supply) 

•  Organizational  (e.g.  Supply  Center  Curtis  Bay) 

•  Application  system  (e.g.  CM+) 

•  Database  (e.g.  Cutter  System  File) 

•  User  view  (e.g.  screen,  report) 

•  Data  flow  in  a  process  model  (e.g.  alteration  data) 

Currently  these  data  models  may  have  inconsistencies  in  their  definitions  of  data 
entities,  relationships,  attributes,  and  physical  data  fields. 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.1.  Data  Architecture  Concepts,  Continued 


Corporate  A  corporate  logistics  data  model  is  a  logical  data  model  for  all  of  CG  fleet  logistics 
Logistics  Data  functions.  As  such,  it  will  depict  the  baseline  of  entities,  relationships,  and 
Model  attributes.  It  will  also  provide  the  basis  for  the  standardized  data  elements  ready  to 

reuse  in  other  data  models. 

A  corporate  logistics  data  model  subsumes  and  represents  all  of  the  views  listed 
above  since  it  is  a  more  comprehensive  and  coordinated  view  of  the  logistics 
business.  Figure  A-1  depicts  the  integration  of  the  various  "view"  models  with  the 
corporate  logistics  data  model  and  the  integration  of  that  model  with  the  Coast 
Guard  data  model.  Initially,  if  there  is  no  "Coast  Guard  data  model",  the  logistics 
data  model  will  constitute  the  initial  content  thereof.  This  model  will  grow  over 
time  as  additional  business  analysis  and  data  analysis  efforts  are  undertaken. 


Figure  A-1.  Relationships  of  Fleet  Logistics  Data  Model 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.1.  Data  Architecture  Concepts,  continued 


Integration  of  Integration  of  data  within  a  whole  corporate  logistics  data  model  or  a  logical  model  of 
Data  Models  subject  area  database  or  an  application  system  (one  or  more)  can  be  accomplished  via: 

•  One  logical/conceptual  schema, 

•  Multiple  external  schema  for  user  views,  or 

•  Multiple  internal  schema  for  physical  databases  which  could  be  located  in 
different  locations. 
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Information  System  Concepts  for  DA 


A.2.  Three-Schema  Architecture 


Three-  The  following  figure,  Three  Schema  Architecture,  depicts  the  "ANSI  Three  Schema 

Schema  Architecture"  in  simple  terms.  The  box  labeled  Conceptual  Schema  represents  a 

Architecture  data  administration  unified  view  of  the  total  information  resources  of  the 

organization.  The  Conceptual  Schema,  or  logical  view,  is  the  result  of  integrating 
all  the  information  models  developed  to  describe  the  various  aspects  of  the  corporate 
information  resource. 

The  boxes  labeled  External  Schema  represent  the  ways  in  which  different  groups  of 
users  view  the  portions  of  the  corporate  information  resource  relevant  to  them. 
External  Schema  are  also  referred  to  as  "user  views"  -  i.e.  when  we  think  about  the 
data  used  by  a  particular  system. 

Finally,  the  boxes  labeled  Internal  Schema  represent  the  actual  physical  storage  of 
data,  which  may  be  stored  in  multiple,  dispersed  databases.  These  multiple 
databases  may  even  use  totally  different  storage  methods. 

The  Conceptual  Schema  has  an  organization-wide  scope,  and  is  quite  stable  with 
respect  to  changes  in  data  processing  technology  or  specific  applications.  The 
External  Schema  have  a  narrow  scope,  change  as  applications  change,  but  are  stable 
with  respect  to  data  management  technology.  Finally,  the  Internal  Schema  change 
as  the  data  management  software  and  hardware  changes,  but  remain  relatively  stable 
with  respect  to  changes  in  applications.  Internal  Schema  change  in  response  to 
changing  database  access  workloads,  since  alterations  in  workload  usually  require 
fine-tuning  the  physical  database  design  to  maximize  performance. 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.2.  Three-Schema  Architecture,  continued 


Three-Tier  Metadata  Model 


Figure  A-2.  Three-Schema  Architecture 


Metadata  The  following  four  figures  depict; 

Models 

•  •  The  Metadata  Model  for  Conceptual  ER  Diagrams,  (A-3) 

•  •  The  Meta  Model  for  Logical  Data  Models  (A-4) 

•  •  The  Meta  Model  Data  for  Mapping  Physical  Data  Models  (A-5) 

•  » The  Meta  Model  for  Data  Element  Standardization  (A-6) 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.2.  Three-Schema  Architecture,  Continued 


Meta  Model  for  Conceptual  ER  Diagrams 


Figure  A-3.  The  Metadata  Model  for  Conceptual  ER  Diagrams 


Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.2.  Three-Schema  Architecture,  continued 


Meta  Model  for  Logical  Data  Models 


r::;;: . . . .  . . 

Logical  Data  Models 


standardized  for  j.  Standard 

.  o  Data  Element 


-1 - 

implennents  ^ 

implements 

ADDlication 

_ ^  Physical 

,  Physical 

/Database  f^^des 

^  File/Table 

structured  into 

^  Data  Field 

Physical  Data  Models 

Figure  A-4.  Meta  Model  For  Logical  Data  Models 


Meta  Model  for  Mapping  Physical  Data  Models 


Figure  A-5.  Meta  Model  Data  For  Mapping  Physical  Data  Models 

Continued  on  next  page 
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Information  System  Concepts  for  DA 


A.2.  Three-Schema  Architecture,  Continued 


Meta  Model  for  Data  Element  Standardization 


Figure  A-6.  Meta  Model  for  Data  Element  Standardization 
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Information  System  Concepts  for  DA 


A.3.  Data  Modeling  Concepts 


Purpose  The  following  information  supports  the  data  modeling  processes  described  in 

Section  3. 


Entity  An  entity  is  a  person,  place,  thing,  concept,  event,  or  activity  about  which  an 

Concept  organization  keeps  information.  Entities  are  named  using  singular  nouns  or  noun 

phrases  to  emphasize  the  fact  that  they  represent  "things." 

Like  nouns,  entities  can  represent  a  wide  variety  of  rather  tangible  lasting  objects 
such  as  people,  vessels,  money,  buildings,  or  equipment  installations  as  well  as  more 
dynamic  events  such  as  equipment  casualties  on  CG  vessels,  supply  requests,  or 
work  assignments.  Identification  of  entities  is  a  crucial  step  in  determining  and 
modeling  the  data  the  CG  must  track. 


Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Entity  Entities  versus  instances:  When  we  speak  about  entities,  we  are  referring  to  types  of 

Concept,  entities  rather  than  instances  /occurrences  of  these  entities, 

continued  For  example,  "Person"  is  a  type  of  entity.  "John  Doe"  is  an  instance  of  that  entity 

type.  As  a  convention,  when  we  refer  to  the  word  "entity"  in  this  document,  we  are 
actually  referring  to  an  entity  type.  Instances  of  entities  will  be  called  "entity 
instances"  or  just  "instances". 

Note  that  the  two  most  important  aspects  of  an  entity  from  a  data  modeling 
viewpoint  are: 

1 .  Its  identity,  that  which  distinguishes  one  instance  of  the  entity  from  all  other 
instances  through  some  unique  identifier  (e.g.  Vessel  Identifier), 

2.  Its  substance,  the  properties  /  attributes  that  hold  for  the  entity,  and  can  be 
discovered  by  investigation  of  the  entity  (e.g.  Vessel  Length). 

Qualification  as  an  entity:  All  instances  of  an  entity  must  have  a  set  of  common 
characteristics  or  attributes  which  describe  them.  Each  instance  of  an  entity  must  be 
uniquely  distinguishable  or  identifiable  from  other  instances  by  some  or  all  of  its 
attributes.  Finally,  entities  must  represent  something  of  lasting  importance  to  the 
enterprise. 

Stability  of  entities:  Unlike  functions  or  procedures  which  tend  to  change  over  time, 
the  data  entities  an  organization  deals  with  are  relatively  stable.  The  Coast  Guard 
has  been  keeping  track  of  vessels,  equipment,  provisions,  maintenance  work 
standards,  money,  buildings,  and  people  since  its  inception. 

The  procedures  used  to  collect  and  maintain  information  about  these  entities  have 
changed  significantly,  but  the  entities  themselves  are  the  same. 

Depiction  of  entities:  Entities  in  a  data  model  are  represented  by  boxes  with  either 
square  or  rounded  comers.  Each  entity  in  a  data  model  must  have  a  unique  name.  A 
unique  number  may  be  designated  for  each  entity.  The  entity  name  and  number  (if 
one  is  designated)  are  placed  on  top  of  the  box.  Attributes  of  the  entity  may  be 
listed  within  the  box. 

Proponency  for  entities:  Proponency  for  an  entity  is  assigned  to  the  proponent  (data 
steward)  of  the  entity's  primary  key  (refer  to  the  topics  Attributes  and  Types  of 
Attributes  below).  Note  that  the  proponent  of  an  entity  is  not  necessarily  the 
proponent  for  all  attributes  of  that  entity. 


Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Types  of  Entities  are  classified  into  categories  /  types  by  the  role  they  have  in  the  model.  This 

Entities  document  presents  five  DoD-compliant  methodology  entity  types,  and  two  other 

types  that  are  used  in  some  methodologies  or  extensions,  but  are  not  part  of  the  DoD 
methodology. 

Independent  entity  (primary  entity):  Also  called  fundamental  entity,  this  is  a  basic 
entity  type  that  exists.  It  is  of  interest  to  the  organization  in  its  own  right  (e.g. 

Vessel,  Person)..  An  instance  of  such  entity  can  be  uniquely  identified 
independently  of  its  relationship  with  any  other  entity.  Independent  entities  are  often 
represented  in  diagrams  as  boxes  with  square  comers. 

Dependent  entity:  An  entity  is  a  dependent  entity  if  unique  identification  of  its 
instances  is  dependent  on  its  relationship(s)  with  an  instance  of  another  entity  (or 
multiple  entities)  that  has  to  exist  already.  For  example,  an  entity  called  Person 
Work  Assignment  is  dependent  on  the  existence  of  the  Person  entity.  Dependent 
entities  are  often  shown  as  boxes  with  rounded  comers. 

Associative  entity:  Also  called  an  association,  exists  primarily  to  interrelate  other 
entities  (e.g.  Vessel  Crew).  Associative  entities  are  always  dependent. 

Generic  entity  (supertype  entity):  Also  called  a  generic  parent,  instances  of  this 
entity  can  be  divided  into  multiple  entity  subclassifications  (e.g.  Person).  A 
discriminator  attribute  (or  set  of  attributes)  is  used  to  determine  which 
subclassification  a  particular  instance  belongs  to. 

Category  entity  (subtype  entity)-.  Each  subclassification  of  a  generic  entity  is  called 
a  category  entity  (e.g.  Officer  entity  is  a  subtype  of  the  Person  entity).  Category 
entities  "inherit"  all  attributes  of  their  generic  parent  entity. 

Attributive  entity:  (non-DoD)  This  variation  of  the  dependent  entity  type  is 
addressed  here  only  for  completeness.  It  is  used  in  some  modeling  techniques  to 
describe  attributes  of  another  entity  (e.g.  Person  Skill  tracks  multiple  skills). 

Aggregate  entity:  (non-DoD)  Also  called  an  aggregate  object,  this  entity  represents 
a  collection  of  other  entities.  While  the  DoD  methodology  does  not  have  a  constmct 
for  designating  aggregate  objects,  this  concept  can  be  useful  when  the  need  arises  to 
show  a  simplified  version  of  the  model. 

An  aggregate  entity  is  essentially  an  abstraction  of  a  group  of  related  entities  (e.g.  it 
may  be  useful  to  define  an  aggregate  entity  Technical  Document). 


Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Relationship  A  relationship  is  an  association  between  two  entities  depicting  a  business  rule.  For 
Concept  example,  the  relationship  "MAINTAINS"  might  be  an  association  between  a 

PERSON  and  a  VESSEL.  A  relationship  is  always  identified  by  a  verb  phrase  that 
describes  the  relationship.  The  relationship  name  may  be  combined  with  the  name  of 
each  entity  to  form  a  sentence  that  describes  the  relationship.  In  the  example,  a 
PERSON  “MAINTAINS”  a  VESSEL.  Two  relationship  names  may  also  be  defined 
for  both  relationship  directions  between  the  two  entities,  for  example,  a  VESSEL 
“IS  MAINTAINED  BY”  a  PERSON. 

Relationships  are  documented  by  the  following  metadata  (data  about  data): 


Relationship  Metadata 

Metadata  Definition 

Relationship  name 

Each  relationship  must  be  named  with  a  verb 
or  verb  phrase.  This  phrase  depicts  the  action 
represented  in  the  relationship.  The  complete 
relationship  name  also  includes  the  entity 
names  in  the  association.  The  name  takes  the 
form 

ENTITY-VERBPHRASE-ENTITY. 

Relationship  definition 

A  complete  description  of  the  business  rule 
which  the  relationship  represents. 

Parent  entity 

The  parent  (sometimes  called  the  source) 
entity  initiates  the  relationship  between 
entities. 

Child  entity(ies) 

The  child  (also  called  the  target)  entity  or 
entities  is  the  destination  of  the  relationship 
from  the  source/parent  entity. 

Relationship  type 

Identifies  the  type  of  relationship  (connection 
or  category). 

Cardinality 

Indicates  the  upper  and  lower  bounds  on  the 
number  of  times  an  instance  of  one  entity  is 
associated  with  another.  Cardinality  must  be 
recorded  for  both  directions  in  the 
relationship. 

Category  discriminator 
(for  category  relationships) 

Distinguishes  between  categories  in  a  category 
relationship. 

Relationships  will  be  evaluated  for  necessity  to  the  application,  reflection  of  the 
business  process,  business  rules,  and  best  use  of  information  resources. 


Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Types  of  Relationships  are  classified  according  to  the  interaction  they  represent  between 

Relationships  entities.  There  are  two  major  types  of  relationships:  connection  and  category. 


Connection  A  connection  relationship,  also  known  as  an  aggregation  relationship,  is  described  as 
Relationships  one  of  four  subtypes: 


Connection  Relationships 

Definition 

Specific  relationships 

A  connection  relationship  where  an  instance  of 

Entity  1  may  be  related  to  zero,  one,  or  many 
instances  of  Entity  2,  but  Entity  2  is  related  to 
exactly  one  instance  of  Entity  1 .  This  is  also  known 
as  a  parent-child  or  one-to-many  relationship.  Entity 

1  is  considered  the  parent  entity,  and  Entity  2  is 
considered  the  child. 

Nonspecific  relationships 

A  connection  relationship  where  many  instances  of 
Entity  1  may  be  associated  with  many  instances  of 
Entity  2.  This  relationship  is  called  many-to-many 
(M:M).  M:M  relationships  cannot  be  directly 
implemented  in  a  relational  database  schema.  These 
relationships  are  eliminated  during  detailed  data 
modeling  through  the  introduction  of  associative 
entities. 

Recursive  relationships 

These  connection  relationships,  also  known  as 
reflexive  relationships,  are  a  special  type  of 
nonspecific  relationship:  they  associate  an  instance 
of  an  entity  with  zero,  one,  or  more  instances  of  the 
same  entity.  Marriage  is  an  example  of  recursive 
relationship  where  an  instance  of  the  entity 

PERSON  is  related  to  another  instance  of  PERSON. 
In  this  case.  Person  1  IS-MARRIED-TO  Person  2. 

Structural  relationships 

A  structural  relationship  is  also  known  as  an 
"is  part  of  or  "bill  of  materials"  relationship.  It 
defines  a  structural  association  between  entities,  one 
of  which  is  a  component  of  the  other.  For  example, 
a  cylinder  IS-PART-OF  an  engine,  which  in  turn  IS- 
PART-OF  a  vehicle  or  vessel. 

Continued  on  next  page 
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Data  Modeling  Concepts,  continued 


Category  Category  relationships  are  also  known  as  "entity  type  hierarchies”,  "is  a  kind  of’,  or 

Relationships  just  "is  a"  relationships.  Figure  A-7  shows  an  example  of  an  entity  type  hierarchy 

relationship.  Category  relationships  represent  an  association  of  one  or  more  entity 
types  with  a  more  general  entity  type.  The  more  general  entity  is  called  the  generic 
parent  or  entity  supertype.  The  lower  level  entities  are  referred  to  as  entity  subtypes 
or  category  entities. 

Category  entities  are  merely  special  classes,  supertypes  or  kinds  of  the  generic 
parent.  Attributes  of  the  generic  parent  apply  to  all  subtypes  of  that  entity.  The 
primary  key  attribute  of  the  parent  must  be  used  as  the  primary  key  for  all  category 
entities.  At  least  one  attribute  of  the  parent  entity  serves  as  a  discriminator  to 
indicate  the  category  to  which  each  instance  belongs. 


Category  Relationships  Exampie 


Cardinality  of  A  relationship  between  two  entities  actually  represents  two  association  directions: 

Relationship  the  association  between  Entity  1  and  Entity  2,  and  the  inverse  association  between 
Entity  2  and  Entity  1.  Instances  of  Entity  1  can  possibly  be  associated  with  zero, 
one,  or  several  instances  of  Entity  2.  The  same  is  true  in  the  other  direction.  The 
property  of  a  relationship  which  designates  how  many  times  an  instance  of  one 
entity  is  associated  with  instances  of  another  is  called  cardinality.  Cardinality  of  a 
relationship  is  expressed  in  a  ratio  such  as  X:Y  where  X  and  Y  are  the  number  of 
instances,  respectively,  of  Entity  1  associated  with  Entity  2,  and  Entity  2  associated 
with  Entity  1 . 

Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Attribute  All  entities  have  properties  or  characteristics  which  can  be  used  to  describe  and 

Concept  distinguish  them.  These  characteristics  are  called  entity  attributes.  They 

characterize  an  entity  much  in  the  same  way  adjectives  and  adverbs  can  be  used  to 
characterize  a  noun.  Attributes  are  identified  and  documented  by  attribute  name, 
definition,  and  type.  The  definition  must  describe  completely  what  the  attribute 
represents  in  the  real  world.  An  attribute  should  describe  one  and  only  one 
conceptual  level  entity  in  an  integrated  corporate  data  model.  In  other  words,  two 
entities  can  not  contain  the  same  attribute,  however,  multiple  subtype  entities  could 
inherit  an  attribute  from  a  supertype  entity. 

Attributes  form  the  basis  for  standard  data  elements.  A  standard  data  element  is  an 
attribute  which  has  been  more  rigorously  defined.  The  data  element  definition  and 
standardization  process  includes  other  attribute  characteristics  such  as  proponency, 
data  value  ownership,  security,  synchronization,  and  validation  rules.  Section  4 
Standardize  Data  Elements  describes  the  rules  and  conventions  for  forming  and 
naming  standard  data  elements. 


Types  of  Attribute  types  may  be  classified  as  being  either  key  or  non-key.  On  an  E-R 

Attributes  diagram,  attributes  are  listed  in  the  box  representing  the  entity  they  describe.  Figure 

A-8  shows  the  relationship  of  these  attribute  types. 

Primary-key  attributes:  The  designated  attribute  or  set  of  attributes  which  uniquely 
identifies  each  entity  instance  is  called  the  primary-key  for  the  entity.  DoD 
modeling  convention  calls  for  primary-key  attributes  to  be  listed  at  the  top  of  the 
box  representing  the  entity.  A  horizontal  line  is  then  drawn  across  the  box 
immediately  below  the  primary  key. 

Foreign-key  attributes:  An  attribute  or  set  of  attributes  that  forms  the  primary  key 
for  another  related  entity  is  called  a  foreign  key.  Foreign  key  attributes  that  are  not 
part  of  the  primary  key  are  listed  below  the  primary  key  line. 

Non-key  attributes:  An  attribute  that  is  not  used  as  part  of  a  key  is  a  non-key 
attribute.  When  non-key  attributes  are  included  in  the  model,  they  appear  below  the 
primary  key  line.  A  "fully  attributed  data  model,"  which  is  delivered  at  the  end  of 
requirements  analysis  phase,  contains  the  known  non-key  attributes  for  each  entity. 

Group  attributes:  A  set  of  attributes  (non-key)  that  have  been  combined  and  given 
a  unique  name  called  a  group  attribute. 


Continued  on  next  page 
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A.3.  Data  Modeling  Concepts,  continued 


Entities  and  Attributes  Example 


Foreign  Key  Attribute 
^ftc^k6^§l0ribute  ''  '■ 

^'f'jNpn-^keyMt^ 

^  Group  Attribute::^ 

;.:iLehg^:^-  .y  t 

Non~key  attribute 

siNtMM^'alMIni^  -lii 

Figure  A-i 

{.  Relationship  of  Attribute  Types 
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CLASS  WORD  DESCRIPTIONS 


List  of  Class 
Word  Names 


The  following  list  of  class  word  names  is  from  the  COMDTINST  5230.42A, 
and  is  in  compliance  with  DoD  Data  Element  Standardization  Procedures, 
DoD  8320.1 -M-1,  January  1993.  Note  this  is  the  subset  of  both  lists  that 
complies  with  both  standards. 


Class  Word 
Name 

Abbreviation 

Description 

AMOUNT 

AM 

A  monetary  value.  (Includes  average, 
balance,  deviation,  factor,  index,  level, 
mean,  mode,  scale,  and  yield.) 

ANGLE 

AN 

The  rotational  measurement  between  two 
lines  and/or  planes  diverging  from  a 
common  point  and  /or  line.  (Includes 
azimuth  and  heading.) 

AREA 

AR 

The  measurement  of  a  surface  expressed  in 
unit  squares  (two  dimensional). 

CODE 

CD 

A  combination  of  one  or  more  numbers, 
letters,  or  special  characters  substituted  for 
a  specific  meaning.  Represents  finite, 
predetermined  values.  (Must  have  a 
specific  domain.)  (Includes  category  and 
status.) 

COORDINATE 

CN 

Designation  of  the  location  of  a  line  or 
plane.  (Includes  latitude  and  longitude.) 

DATE 

DT 

The  designation  of  a  specific  24-hour 
period  of  time. 

DIMENSION 

DM 

A  measured  linear  distance  (one 
dimensional).  (Includes  altitude,  depth, 
diameter,  elevation,  height,  length,  radius, 
vertex,  and  width.) 

Continued  on  next  page 
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Class  Word  Name 

Abbreviation 

Description 

IDENTIFIER 

TD 

A  combination  of  one  or  more  numbers, 
letters,  or  special  characters  that 
designate  a  specific  object/entity  but  that 
have  no  readily  definable  meaning. 

(They  must  have  a  general  domain.) 
(Includes  designator,  key,  number.) 

MASS 

MS 

The  measure  of  inertia  of  a  body. 

NAME 

NM 

A  designation  of  an  object  and/or  entity 
expressed  in  a  word  or  phrase. 

QUANTITY 

QY 

A  non-monetary  numeric  value. 

(Includes  average,  balance,  count, 
deviation,  factor,  index,  level,  mean, 
median,  mode,  and  scale.) 

RATE 

RT 

A  quantity  or  degree  of  something  in 
relation  to  units  of  something  else  (e.g., 
miles  per  gallon).  (Includes  acceleration, 
density,  factor,  flow,  force,  frequency, 
humidity,  impedance,  inductance, 
intensity,  magnitude,  moment,  percent, 
power,  pressure,  resistance,  scale,  speed, 
tension,  torque,  velocity,  viscosity,  and 
voltage.) 

TEMPERATURE 

TP 

The  measure  of  heat  in  an  object  or 
space. 

TEXT 

TX 

An  unformatted  character  string, 
generally  in  the  form  of  words. 

(Includes  category  and  comments.) 

TIME 

TM 

A  designation  of  a  specified 
chronological  point  within  a  period. 

VOLUME 

VL 

Measurement  of  space  occupied  by  a 
three-dimensional  figure  as  measured  in 
cubic  units. 

WEIGHT 

WT 

The  force  with  which  an  object  is 
attracted  toward  the  earth  and/or  another 
celestial  body  by  gravitation. 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS 


Introduction 


Data  Element 
Attribute  List 


The  following  alphabetical  list  of  data  element  attributes  should  be  recorded 
accordingly  for  each  data  element  submitted  as  a  candidate  for 
standardization.  These  attributes  will  change  over  time  through  the  change 
control  process  after  recommendations  are  made  to  fleet  logistics  DA.  Refer 
to  the  fleet  logistics  DA  repository  for  the  most  up-to-date  versions  of  these 
attributes  (see  Section  6,  Implement  Metadata  Repository,  for  more 
information  on  attribute  versions). 


The  following  is  the  list  of  data  element  attributes.  For  each  attribute  there  is 
a  definition  for  the  “domain  definition,”  “length,”  “type,”  and  “edit” 
associated  with  that  data  element  attribute. 

Note  that  items  A  through  T  are  attributes  associated  with  the  Class  Word 
component  of  the  Data  Element.  Items  U  through  AU  are  attributes 
associated  with  the  Prime  Word  component  of  the  Data  Element. 

Because  Class  Words  are  relatively  static  compared  with  Prime  Words  and 
Data  Elements,  it  will  be  the  rare  case  that  you  will  need  to  modify  or  create  a 
Class  Word.  In  the  automated  tool  to  assist  in  Data  Element  creation,  all  of 
the  values  for  the  attributes  of  the  Data  Element’s  associated  Class  Word  will 
be  automatically  reflected  in  the  Data  Element  definition.  Prime  Word 
attributes  that  are  bounded  by  their  associated  Class  Word  attrubutes  (such  as 
“definition,”  or  “justification”)  will  be  automatically  filled  in  with  the 
associated  Class  Word  attribute  value,  and  are  modifiable  if  necessary.  Refer 
to  Section  6,  Implement  Metadata  Repository,  for  more  informaiton  on  the 
automated  tool  for  accessing  the  data  repository. 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


A.  Automated 

Definition: 

Identification  of  the  data  entity  this  data  element  is 

Data  Entity 

associated  with. 

Identifier 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 
ASCII  character  set. 

Length: 

35 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

B.  Automated 

Definition: 

The  name  of  a  standard  process  that  adds,  modifies. 

Standard 

and  deletes  a  standard  data  element. 

Process 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Names 

ASCII  character  set. 

Length: 

250 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

C.  Class 

Definition: 

Freeform  text  that  describes  the  authority  for  and/or 

Word 

references  supporting  the  existence  of  a  particular  class 

Authority 

word. 

Reference 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute. 

D.  Class 

Definition: 

The  word  that  identifies  a  specific  category  of  data 

Word  Name 

(e.g.,  date,  dimension,  and  code,  etc.)  that  will  be 
represented  by  data  values  of  a  standard  data  element 
associated  with  a  particular  class  word. 

Domain  Definition: 

A  specific  domain  comprising  the  qualitative  data 
values  listed  in  procedure  4.2. 1.4,  Identify  the  Class 
Word  Name  and  Modifier(s). 

Length: 

80 

Type: 

Alphabetic 

Edit: 

Required  attribute.  The  class  word  must  be  in  class 

word  table  in  an  approved  status  unless  creating  a  new 
class  word. 


Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


D.  Class  Word  Name  (continued) 


E.  Class 

Definition; 

The  number  identifying  the  location  of  the  class  word 

Word  Position 

in  the  data  element  name. 

identifier 

Domain  Definition; 

A  general  domain  comprising  up  to  two  of  the 
following  integer  values:  1-99. 

Length; 

2 

Type; 

Integer 

Edit; 

Required  attribute 

F.  Class 

Definition: 

The  quantity  of  decimal  places  allowable  for  a  given 

Word  Decimal 

class  word 

Place  Count 

Domain  Definition: 

A  general  domain  comprised  the  ASCII  characters:  0- 

Quantity 

99. 

Length: 

2 

Type: 

Numeric 

Edit; 

Required  attribute  for  class  word  only  if  the  class  won 

type  name  is  fixed-point.  This  attribute  is  displayed  at 
the  data  element  level  and  cannot  be  changed. 


G.  Class 

Definition: 

Freeform  text  that  represents  the  definition  of  a  given 

Word 

class  word. 

Definition 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

H.  Class 

Definition: 

Freeform  text  that  describes  the  overall  meaning  or 

Word  Domain 

general  characteristics  of  the  domain  of  a  particular 

Definition 

class  word. 

Text 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 
ASCII  character  set. 

Length: 

999 

Type; 

Alpha-numeric 

Edit: 

Required  attribute. 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


H.  Class  Word  Domain  Definition  Text  (continued) 


1.  Class  Word 

Definition; 

Freeform  text  describes  the  meaning  of  a  domain  value 

Domain  Value 

of  a  given  class  word. 

Definition 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Required  attribute  if  there  are  no  low-range  or  high- 
range  identifiers. 

J.  Class 

Definition: 

The  unique  identifier  that  represents  a  particular  value 

Word  Domain 

within  the  domain  of  a  specific  class  word. 

Value 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 

Identifier 

characters:  A-Z,  0-9,  hyphen  (-),  point  (.),  slash  (/), 
underscore  (_)»  and  ampersand  (&). 

Length: 

35 

Type: 

Alpha-numeric 

Edit: 

Required  attribute  for  quantitative  data  if  there  are  no 
low-range  and  high-range  identifiers  or  no  source  list 
text. 

K.  Class 

Definition: 

The  unique  identifier  that  denotes  the  highest  allowable 

Word  High- 

value  permitted  in  the  domain  range  of  a  given  class 

Range 

word. 

Identifier 

Domain  Definition: 

A  general  domain  comprising  all  real  numbers. 

Length: 

15 

Type: 

Numeric 

Edit: 

Required  attribute  if  there  are  no  domain  value 
identifiers  or  source  list  text.  If  there  is  a  high-range 

identifier,  it  must  not  be  greater  than  the  maximum 
character  count  quantity. 


Continued  on  next  page 


C-4 


Data  Element  Attribute  Descriptions 


DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


K.  Class  Word  High-Range  Identifier  (continued) 


L  Class 

Definition: 

The  unique  identifier  that  denotes  the  lowest  allowable 

Word  Low- 

value  permitted  in  the  domain  range  of  a  given  class 

Range 

word. 

Identifier 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 
characters:  0-9,  point  (.),  and  minus  (-). 

Length: 

15 

Type: 

Numeric 

Edit: 

Required  attribute  if  there  are  no  domain  value 
identifiers  or  source  list  text. 

M.  Class 

Definition: 

The  maximum  quantity  of  characters  that  can  be  stored 

Word 

for  a  domain  value  associated  with  a  given  class  word. 

Maximum 

Domain  Definition: 

A  specific  domain  of  quantitative  data  values  ranging 

Character 

from  0001-9999. 

Count 

Length: 

4 

Quantity 

Type: 

Numeric 

Edit: 

Required  attribute. 

N.  Class 

Definition: 

The  long  standard  name  of  a  specific  type  of  data 

Word  Name 

element  (class  word)  that  describes  and  identifies  a 
generic  structure  and  domain.  A  class  word  has  no 
organizational  or  application  context.  The  structured 
name  format  comprises  zero  to  “n”  modifiers  and  one 

class  word.  The  general  name  format  comprises: 
modifier  and/or  modifier  and/or  class  word. 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 
characters:  A-Z,  hyphen  (-),  and  space. 

Length: 

80 

Type: 

Alpha-numeric 

Edit: 

Required  attribute.  The  class  word  must  be  in  the  class 
word  table  unless  the  user  is  creating  a  new  class  word. 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


0.  Class  Definition:  A  code  that  defines  the  security  classification  of  the 

Word  Security  existence  of  a  specific  class  word  or  its  metadata. 

Classification  Domain  Definition:  A  specific  domain  comprising  the  following  qualitative 
Narne  data  values: 

•  NATO  (North  Atlantic  Treaty  Organization)  Top 
Secret  Atomal 

•  NATO  Top  Secret 

•  Top  Secret 

•  NATO  Secret  Atomal 

•  NATO  Secret 

•  Secret  Restricted 

•  NATO  Confidential  Atomal 

•  NATO  Confidential 

•  Confidential 

•  Confidential  Restricted 

•  NATO  Restricted 

•  For  Official  Use  Only 

•  Unclassified  Sensitive 

•  Unclassified 


Length: 

25 

Type: 

Alphabetic 

Edit: 

Required  attribute.  The  default  is  unclassified  (may  be 
changed). 

P.  Class 

Definition: 

The  name  of  the  data  type  associated  with  a  specific 

Word  Type 

class  word. 

Name 

Domain  Definition: 

A  specific  domain  comprising  the  following  qualitative 
data  values:  bit-string,  integer,  character  string,  fixed- 
point,  and  floating-point. 

Length: 

16 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


P.  Class  Word  Type  Name  (continued) 


Q. 

Definition: 

The  positional  justification  of  data  values  within  a 

Information 

storage  field. 

Element 

Domain  Definition: 

A  specific  domain  comprising  the  following  qualitative 

Justification 

data  values:  left  and  right. 

Category 

Length: 

5 

Name 

Type: 

Alphabetic 

Edit: 

Required  attribute  for  a  class  word  and  display  only  for 
a  data  element. 

R.  Information 

Definition: 

The  branch  of  service,  government,  or  international 

Element 

organization  that  approved  the  element. 

Standardi¬ 

Domain  Definition: 

A  specific  domain  comprising  the  following  qualitative 

zation 

data  values: 

Authority 

•  ANSI  American  National  Standards  Institute 

Code 

•  DOD  Department  of  Defense 

•  FIPS  Federal  Information  Processing 

Standards 

•  ISO  International  Organization  for 

Standardization 

•  NATO  North  Atlantic  Treaty  Organization 

•  USCG  United  States  Coast  Guard 

Length: 

4 

Type: 

Alphabetic 

Edit: 

Optional  attribute 

S.  information 

Definition: 

An  indicator  of  how  accurate  a  qualitative  data  value 

Qualitative 

must  be. 

Data  Value 

Domain  Definition: 

A  specific  domain  comprising  qualitative  data  values 

Accuracy 

(0-9)  ranging  from  1  to  100. 

Number 

Length: 

3 

Percent  Rate 

Type: 

Numeric 

Edit: 

Required  attribute  if  data  is  qualitative. 

Continued  on  next  page 
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Data  Element  Attribute  Descriptions 


DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


S.  Information  Qualitative  Data  Value  Accuracy  Number  Percent  Rate  (continued) 


T.  Information  Definition: 
Quantitative 

Data  Domain  Definition: 

Accuracy 

Code 


Length: 

Type: 

Edit: 


A  character  string  indicating  how  accurate  a 
quantitative  data  value  must  be. 

A  specific  domain  comprising  the  following  qualitative 
data  values: 

•  1  nearest  million 

•  2  nearest  100,000 

•  3  nearest  10,000 

•  4  nearest  1 ,000 

•  5  nearest  100 

•  6  nearest  10 

•  7  nearest  1 

•  8  nearest  .1 

•  9  nearest  .01 

•  10  nearest  .001 

•  1 1  nearest  .0001 

•  12  nearest  .00001 

•  99  none 
2 

Numeric 

Required  attribute  if  data  is  quantitative 


U.  Prime  Definition:  The  name  of  the  primary  object  (i.e.,  person,  place. 

Word  Name  thing,  or  concept)  of  interest  that  a  given  data  element 

describes. 

Domain  Definition:  A  general  domain  comprised  the  ASCII  characters  A-Z 
and  hyphen  (-). 

Length:  170 

Type:  Alphabetic 

Edit:  Required  attribute.  The  prime  word  name  is  a  variable 

length  field  comprising  zero  to  n  modifiers  and  a  prime 

word. 


Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


U,  Prime  Word  Name  (continued) 


V.  Prime 

Definition: 

A  narrative  describing  the  context  of  a  principal  term 

Word  Name 

that  has  a  precise  meaning  as  it  relates  to  an  entity 

Definition 

standard. 

Text 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 
ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

W.  Prime 

Definition: 

The  designated  proponent  for  each  prime  word  name 

Word  Steward 

derived  from  an  information  model. 

Name 

Domain  Definition: 

A  general  domain  comprising  the  following:  TBS 

Length: 

10 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

X.  Prime 

Definition: 

The  name  of  the  proponent  for  which  the  prime  word 

Word  Using 

name  is  contained  in  an  information  model. 

Proponent 

Domain  Definition: 

A  general  domain  comprising  the  ASCII  character  set. 

Model  Name 

Length: 

10 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute 

Y,  Prime 

Definition: 

A  character  string  that  further  describes  a  characteristic 

Word  Modifier 

of  an  object,  a  relationship  between  objects  or  the 

Name 

object  itself. 

Domain  Definition: 

A  general  domain  comprising  the  ASCII  characters:  A- 
Z,  hyphen  (-),  and  underscore  (_). 

Length: 

170 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute.  Cannot  be  a  class  word. 

Z.  Prime 

Definition: 

The  number  identifying  the  location  of  the  prime  word 

Word  Position 

name  in  the  data  element  name. 

Identifier 

Domain  Definition: 

A  general  domain  comprising  integer  values  0-9 

Length: 

2 

Type: 

Numeric 

Edit: 

Required  attribute 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 

Z  Prime  Word  Position  Identifier  (continued) 


AA.  Standard 

Definition: 

An  abbreviated  name  representing  the  specific  data 

Data  Element 

element.  An  access  name  is  used  to  reference  a  data 

Access  Name 

element  in  a  database  and  must  conform  to  the 

S5mtactical  requirements  of  the  database  management 
system  (DBMS)  or  programming  language  of  the 
application  in  which  a  data  element  is  used. 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 
characters:  A-Z,  0-9,  hyphen  (-),  underscore  (_),  and 
period  (.). 

Length: 

30 

Type: 

Alpha-numeric 

Edit: 

Required  at  the  time  a  data  element  is  identified  for  use 
in  an  automated  system. 

AB.  Standard 

Definition: 

Freeform  text  that  describes  the  authority  for  and/or 

Data  Element 

references  supporting  the  existence  of  a  particular  data 

Authority 

element. 

Reference 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute 

AC.  Standard 

Definition: 

An  administrative  narrative  regarding  a  class  word, 

Data  Element 

standard  data  element,  or  nonstandard  data  element. 

Comment 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute 

AD.  Standard 

Definition: 

A  code  that  denotes  the  Coast  Guard  organization  that 

Data  Element 

uses  a  given  data  element  within  its  systems 

Component 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Code 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute 

Continued  on  next  page 
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Data  Element  Attribute  Descriptions 


DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


AE.  Standard 

Definition: 

The  source  in  which  a  lengthy  list  of  data  values  is 

Data  Element 

enumerated. 

Data  Value 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Source  List 

ASCII  character  set. 

Text 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute.  For  qualitative  data  if  you  have 
source  list  text,  you  will  not  have  domain  value 
identifiers. 

AF.  Standard 

Definition: 

The  quantity  of  decimal  places  allowable  for  a  given 

Data  Element 

data  element. 

Decimal  Place 

Domain  Definition: 

A  general  domain  comprising  the  ASCII  characters  0-9. 

Count 

Length: 

2 

Quantity 

Type: 

Numeric 

Edit: 

Required  attribute  for  class  word  if  element  type  name 
is  fixed-point.  This  attribute  is  displayed  at  the  data 
element  level  and  cannot  be  charged.  If  there  is  a 
decimal  place  count  quantity  at  the  class  word  level  and 
the  element  type  name  is  other  than  fixed-point,  the 
system  will  display  the  decimal  place  count  quantity, 
and  it  can  be  changed  to  be  equal  to  or  less  than  the 
decimal  place  count  quantity  at  the  class  word  level. 

AG.  Standard 

Definition: 

Freeform  text  that  represents  the  definition  of  a  given 

Data  Element 

data  element. 

Definition 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

Continued  on  next  page 
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Data  Element  Attribute  Descriptions 

DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 

AG.  Standard  Data  Element  Definition  Text  (continued) 

AH.  Standard 

Definition: 

Freeform  text  that  describes  the  overall  meaning  or 

Data  Element 

generic  characteristics  of  the  domain  of  a  specific  data 

Domain 

element. 

Definition 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

Required  attribute  (entered  at  class  word  level  and 
displayed  at  data  element  level).  It  can  be  changed  at 
data  element  level. 

Al.  Standard 

Definition: 

Freeform  text  that  describes  the  meaning  of  a  domain 

Data  Element 

value  of  a  given  data  element. 

Domain  Value 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Definition 

ASCII  character  set. 

Text 

Length: 

999 

Type: 

Alpha-numeric 

Edit: 

If  there  are  domain  value  definitions  at  the  class  word 
level,  they  will  be  displayed  at  the  data  element  level. 

If  the  domain  value  identifier  is  deleted,  the  domain 
value  definition  will  be  deleted  at  the  same  time.  The 
domain  value  identifiers  and  definitions  must  be  the 
same  or  a  subset  of  the  class  word. 

AJ.  Standard 

Definition: 

The  unique  identifier  that  represents  a  value  within  the 

Data  Element 

domain  of  a  specific  data  element. 

Domain  Value 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 

identifier 

characters:  A-Z,  0-9,  hyphen  (-),  point  (.),  0-9,  slash  (/), 
underscore  (_),  and  ampersand  (&).  When  the  data 
element  is  quantitative,  allowable  values  are  0-9  and 
decimal  point(.). 

Length: 

35 

Type: 

Alpha-numeric 

Edit: 

If  there  are  domain  value  identifiers,  there  will  not  be  a 
high-range  and  low-range  identifier.  If  there  are 
domain  value  identifiers  at  the  class  word  level,  the 
system  will  display  them  at  the  data  element  level. 

They  can  be  changed  but  must  be  the  same  set  or  subset 
of  the  class  word. 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS, 


AJ.  Standard  Data  Element  Domain  Value  Identifier  (continued) 


AK.  Standard 

Definition: 

Freeform  text  that  describes  the  specific  mathematical 

Data  Element 

formula  or  process  required  to  calculate  the  value  of  a 

Formula 

given  quantitative  data  element. 

Definition 

Domain  Definition; 

A  general  domain  comprising  the  characters  in  the 

Text 

ASCII  character  set. 

Length; 

999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute. 

AL.  Standard 

Definition; 

A  unique  identifier  that  denotes  the  highest  allowable 

Data  Element 

quantity  permitted  in  the  range  of  domain  values  of  a 

High-Range 

given  data  element. 

Identifier 

Domain  Definition: 

A  general  domain  comprising  the  set  of  all  real 
numbers. 

Length: 

15 

Type: 

Numeric 

Edit: 

If  there  is  a  high-range  identifier  at  the  class  word  level, 
the  system  will  display  it.  It  can  be  changed  to  be 
equal  to  or  less  than  the  high-range  identifier  of  the 
class  word.  If  there  is  a  high-range  identifier,  it  must 
not  be  greater  than  the  maximum  capable  of  being 
stored  according  to  the  character  count  quantity  of  the 
data  element. 

AM.  Standard 

Definition: 

A  unique  identifier  that  denotes  the  lowest  allowable 

Data  Element 

quantity  permitted  in  the  range  of  the  domain  values  of 

Low-Range 

a  given  data  element. 

identifier 

Domain  Definition: 

A  general  domain  comprising  the  set  of  all  real 
numbers 

Length: 

15 

Type: 

Numeric 

Edit: 

If  there  is  a  low-range  identifier  at  the  class  word  level, 
this  value  should  be  made  equal  to  or  greater  than  the 
low-range  identifier  of  the  class  word. 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS,  Continued 


AM.  Standard  Data  Element  Low-Range  Identifier  (continued) 


AN.  Standard 

Definition: 

The  maximum  quantity  of  characters  that  can  be  stored 

Data  Element 

for  a  data  element 

Maximum 

Domain  Definition: 

A  general  domain  comprising  integer  values  ranging 

Character 

from  1  to  9999. 

Count 

Length: 

4 

Quantity 

Type: 

Numeric 

Edit: 

Required  attribute.  This  is  a  display  field  brought  over 
from  the  class  word.  This  field  can  be  less  than  the 
length  of  the  class  word. 

AO.  Standard 

Definition: 

The  long  standard  name  that  describes  and  identifies  a 

Data  Element 

given  data  element.  Structured  name  format  will 

Name 

consist  of  a  prime  word  name  and  a  class  word  name. 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 
characters:  A-Z  and  hyphen  (-). 

Length: 

250 

Type: 

Alpha-numeric 

Edit: 

Required  attribute.  Class  word  name  indicated  must  be 
a  DOD-approved  element.  The  data  element  name 
cannot  already  exist  in  the  DDRS. 

AP.  Standard 

Definition: 

The  name  of  the  office  that  originated  or  proposed  the 

Data  Element 

metadata  about  a  specific  element. 

Origin  Office 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Name 

ASCII  character  set. 

Length: 

100 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

AO.  Standard 

Definition: 

A  narrative  that  provides  remarks  pertinent  to  the 

Data  Element 

evaluation  of  a  candidate  element. 

Review 

Domain  Definition: 

A  general  domain  comprising  the  characters  in  the 

Comment 

ASCII  character  set. 

Text 

Length: 

9999 

Type: 

Alpha-numeric 

Edit: 

Optional  attribute. 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS,  Continued 


AR.  Standard 

Definition: 

AQ.  Standard  Data  Element  Review  Comment  Text  (continued) 

A  code  defines  the  security  classification  of  the 

Data  Element 

existence  of  a  given  data  element  and  its  metadata. 

Security 

Domain  Definition: 

A  specific  domain  comprising  the  following  qualitative 

Classification 

data  values: 

Name 

•  NATO  top  secret  atomal 

•  NATO  top  secret 

•  Top  secret 

•  NATO  secret  atomal 

•  NATO  secret 

•  Secret 

•  Secret  restricted 

•  NATO  confidential  atomal 

•  NATO  confidential 

•  Confidential 

•  Confidential  restricted 

•  NATO  restricted 

•  For  official  use  only 

•  Unclassified  sensitive 

•  Unclassified 


Length: 

25 

Type: 

Alphabetic 

Edit: 

Required  attribute.  Default  is  unclassified. 

AS.  Standard 

Definition: 

The  name  of  the  office  responsible  for  managing  the 

Data  Element 

metadata  of  a  specific  data  element. 

Steward 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 

Name 

characters:  A-Z,  hyphen  (-),  and  0-9. 

Length: 

250 

Type: 

Alpha-numeric 

Edit: 

Required  attribute 

Continued  on  next  page 
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DATA  ELEMENT  ATTRIBUTE  DESCRIPTIONS,  Continued 


AS.  Standard  Data  Element  Steward  Name  (continued) 


AT.  Standard 

Definition: 

An  indication  of  how  often  data  values  must  be 

Data  Element 

updated. 

Timeliness 

Domain  Definition: 

A  specific  domain  comprising  the  following  qualitative 

Code 

data  values: 

•  AR 

As  Required 

•  A 

Annually 

•  BI 

Biennially 

•  BM 

Bimonthly 

•  BW 

Biweekly 

•  D 

Daily 

•  H 

Hourly 

•  M 

Monthly 

•  OT 

One  Time 

•  Q 

Quarterly 

•  QDY 

Quarter  Day 

•  Ql 

Quinquennially 

•  QD 

Quadrennially 

•  RT 

Real  Time 

•  SA 

Semiannually 

•  TD 

Twice  Daily 

•  TH 

Twice  Hourly 

•  TRA 

Thrice  Annually 

•  TRI 

Triennially 

•  Z 

None 

Length: 

3 

Type: 

Alphabetic 

Edit: 

Required  attribute 

AU.  Standard 

Definition: 

The  word  or  combination  of  words  that  express  the 

Data  Element 

designation  of  how  the  data  values  for  a  data  element 

Unit  Measure 

are  measured  (e.g..  Inches,  Pounds,  Dollars,  Gallons). 

Name 

Domain  Definition: 

A  general  domain  comprising  the  following  ASCII 

characters:  A-Z,  hyphen  (-),  and  slash  (/). 

Length: 

30 

Type: 

Alpha-numeric 

Edit: 

Required  attribute  for  elements  containing  quantitative 

class  names 
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APPENDIX  D 

FORMS  AND  WORKSHEETS 


Introduction 


The  intent  of  this  manual  is  that  the  data  administration  guidelines,  including  forms, 
are  product-independent.  Use  of  these  forms  and  worksheets  ensures  that  candidate 
data  elements  will  be  defined  to  be  consistent  with  DoD  as  well  as  Coast  Guard 
metadata,  and  industry-standard  repository  tools. 

Note:  In  an  automated  system,  a  number  of  the  fields  on  the  Data  Element 
Development  Worksheet  and  Data  Element  Request  form  would  be  pre-filled  based 
on  the  selected  Class  Word  and  Data  Steward. 
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Data  Element  Development  Worksheet 
and  Data  Element  Request 


TO:  US  Coast  Guard  Data  Administration  FROM:  (Originator 

Address  & 

Address  Telephone) 


1.  TYPE  OF  SUBMITTAL:  (Mark  one) _ New  Candidate _ Archive  Candidate 

_ Modified  Candidate 


2.  DATA  ELEMENT  NAME: 
{Mandatory) 


(Modifier)  (Prime  (Modifier)  (Modifier)  (Modifier)  (Modifier)(Class  (Qualifier)  (Qualifier) 
Word)  Word) 

Optional  Mandatory  Optional . >  Mandatory  Optional- . > 


3.  DATA  ELEMENT  DEFINITION  TEXT: 

(Enter  a  narrative  describing  the  meaning  of  the  data  element  name.) 

4.  AUTOMATED  INFORMATION  SOFTWARE  SYSTEM  IDENTIFIER 

5.  AUTOMATED  INFORMATION  SOFTWARE  SYSTEM  NAME 

6.  CLASS  WORD  AUTHORITY  REFERENCE  TEXT 

7.  CLASS  WORD  CLASS  WORD  POSITION  IDENTIFIER 

8.  CLASS  WORD  DECIMAL  PLACE  COUNT  QUANTITY 

9.  CLASS  WORD  DEHNITION  TEXT 

1 0.  CLASS  WORD  DOMAIN  DEFINITION  TEXT 

1 1 .  CLASS  WORD  DOMAIN  VALUE  DEFINITION  TEXT 

12.  CLASS  WORD  DOMAIN  VALUE  IDENTIFIER 
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13.  CLASS  WORD  HIGH-RANGE  IDENTFIER 

1 4.  CLASS  WORD  LOW-RANGE  IDENTIHER 

15.  CLASS  WORD  MAXIMUM  CHARACTER  COUNT  QUANTITY 

1 6.  CLASS  WORD  SECURITY  CLASSIHCATION  NAME 

1 7.  CLASS  WORD  TYPE  NAME 

\ 

1 8.  INFORMATION  ELEMENT  JUSTIFICATION  CATEGORY  NAME 

1 9.  INFORMATION  ELEMENT  STANDARDIZATION  AUTHORITY  CODE 

20.  INFORMATION  QUALITATIVE  DATA  VALUE  ACCURACY  NUMBER  PERCENT 
RATE 

21 .  INFORMATION  QUANTITATIVE  DATA  ACCURACY  CODE 

22.  PRIME  WORD  NAME  DEHNITION  TEXT 

23.  PRIME  WORD  STEWARD  NAME 

24.  PRIME  WORD  USING  PROPONENT  MODEL  NAME 

25.  PRIME  WORD  POSITION  IDENTIHER 

26.  STANDARD  DATA  ELEMENT  ACCESS  NAME 

27.  STANDARD  DATA  ELEMENT  AUTHORITY  REFERENCE  TEXT 

28.  STANDARD  DATA  ELEMENT  COMMENT  TEXT 
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29.  STANDARD  DATA  ELEMENT  COMPONENT  CODE 

30.  STANDARD  DATA  ELEMENT  DATA  VALUE  SOURCE  LIST  TEXT 

3 1 .  STANDARD  DATA  ELEMENT  DECIMAL  PLACE  COUNT  QUANTITY 

32.  STANDARD  DATA  ELEMENT  DEHNITION  TEXT 

33.  STANDARD  DATA  ELEMENT  DOMAIN  DEHNITION  TEXT 

34.  STANDARD  DATA  ELEMENT  DOMAIN  VALUE  DEHNITION  TEXT 

35.  STANDARD  DATA  ELEMENT  DOMAIN  VALUE  IDENTMER 

36.  STANDARD  DATA  ELEMENT  FORMULA  DEHNITION  TEXT 

37.  STANDARD  DATA  ELEMENT  HIGH-RANGE  IDENTMER 

38.  STANDARD  DATA  ELEMENT  LOW-RANGE  IDENTIFIER 

39.  STANDARD  DATA  ELEMENT  MAXIMUM  CHARACTER  COUNT  QUANTITY 

40.  STANDARD  DATA  ELEMENT  ORIGIN  OFHCE  NAME 

41 .  STANDARD  DATA  ELEMENT  REVIEW  COMMENT  TEXT 

42.  STANDARD  DATA  ELEMENT  SECURITY  CLASSMCATION  NAME 

43.  STANDARD  DATA  ELEMENT  STEWARD  NAME 

44.  STANDARD  DATA  ELEMENT  TIMELINESS  CODE 

45.  STANDARD  DATA  ELEMENT  UNIT  MEASURE  NAME 
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Fleet  Logistics  Data  Administration  Program 


Identification 
of  Submittals 


Metadata  Submittal  Checklist 


Use  this  checklist  when  preparing  or  receiving  a  metadata  package.  The  data 
model  submittal  package  includes  the  following  components: 


Item 

Description 

1 

Application,  project,  or  function  name  and  identifier 

■ 

2 

Coast  Guard  sponsoring  organization  and  point  of 
contact 

3 

Function  or  project  data  administrator  name  and 
organization 

4 

Submittal  date 

5 

Version  number  and  date  of  the  subset  (view)  standard 
metadata  that  was  provided  to  initiate  this  modeling 
process 

6 

Version  number  and  date  of  the  enterprise  data  model  the 
proposal  is  being  compared  to 

7 

Information  systems  within  the  CG  with  which  the 
application  shares  data 

8 

Information  systems  outside  the  CG  with  which  the 
application  shares  data 

9 

Information  system(s)  supported  by  the  E-R  Diagram 

10 

Model  component  count 

11 

CASE  Tool  (and  version)  used  to  generate  the  E-R 

Diagram 

Checked  by:  _ Date: 

Identifier:  _ 

Disposition: 
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Fleet  Logistics  Data  Administration  Program 


Metadata  Submittal  identifier 


Metadata  Identifiers 


Metadata  Item  Name: 

Submitted  as  Part  of: 

□  Conceptuai  model 

□  Logical  data  model 

□  Attributed  data  model 

□  Request  for  Change  in 
Standard  Metadata) 

Metadata  Item  Type 

□  Entity, 

n  Relationship, 

□  Attribute  or  Data 
Element) 

D  Other: 

Security  Designation  or  Other  Restrictions: 

Date  of  Submittal  from 
Developer/Requester  to  DA: 

CASE  tool  and  version 
used:  ’ 

Version  number  and  date  of  the  fleet  logistics 
standard  data  model  referenced  by  this  request  or 
submittal: 

CDRL  Number(s)  of 

Related  DBDD(s)  and 
IDD(s):  * 

other  identifiers: 

FL  DA  Reauest  Identifier:  1 

*  Not  applicable  for  requests  submitted  by  Data  Stewards  or  Quality  Action  Teams. 


Submitter  Identifiers 


System,  Project,  or  Business  Process  Name:  Abbreviation:  Contract  Number  or 

Other  Prog.  Identifier: 

Coast  Guard  Proponent  Organization: 

Program  Manager's  Name:  * 

PM  Org.  Code:  * 

PM  Phone:  * 

Acquisition  or  Funding  Organization:  * 

Acquisition  Contracting  POC: 
(COTR,  Budget  Manager):  * 

Acquisition  (or 
Funding)  Org. 

Code:  * 

Acq.  POC 
Phone:  * 

Submitter  Organization  Name: 

Data  Administration  Point  of 
Contact  Name: 

Submitter  POC 

Org.  Code: 

DA  POC 
Phone: 

Submitter  Org.  Address: 

ConfIg.  Mgmt.  POC: 

CM  Org.  Code: 

CM  Phone: 

Other  Orq.  Identifiers: 

Request; 


Systems  Supported  or  Affected  by  Request: 


Use  this  format  as  a  cover  sheet  for  submittals  of  metadata  deliverables,  resolution  of  discrepancies,  and  change 
requests. 
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Fleet  Logistics  Data  Administration  Program 


Metadata  Request  Log 


Log-in  each  request  with  Req,  ID,  date,  req.  DA,  type,  and  suspense  date. 


Request  Date  Requesting  Program  Name.  Request  Type 

Identifier  Rec’d  Organization 

(DA- 

Assigned) 


Dates: 


Date  Requesting 

Program  Name. 

Request  Type 

Format 

Stewards 

Disposition 

Response 

Rec’d  Organization 

Checked 

Assigned 

Date 

by/date 

by/date 

Retain  original  in  DA  records  for  5  years. 


Fleet  Logistics  Data  Administration  Program 


Submitter  Identifiers 


Metadata  Discrepancy  Report 


System,  Project,  or  Business  Process  Name: 


Abbreviation: 


Contract  Number  or 
Other  Prog.  Identifier: 


Coast  Guard  Proponent  Organization: 


Program  Manager's  Name: 


PM  Org.  Code: 


PM  Phone: 


Acquisition  or  Funding  Organization: 


Acquisition  Contracting  POC: 
(COTR,  Budget  Manager):  * 


Acquisition  (or 
Funding)  Org. 
Code:  * 


Acq.  POC 
Phone:  * 


Submitter  Organization  Name: 


Data  Administration  Point  of 
Contact  Name: 


Submitter  POC 
Org.  Code: 


DA  POC 
Phone: 


Submitter  Org.  Address: 


Config.  Mgmt.  POC: 


CM  Org.  Code: 


CM  Phone: 


Other  Org.  Identifiers: 


Metadata  Identifiers 


Metadata  Item  Name: 


Security  Designation  or  Other  Restrictions: 


Submitted  as  Part  of: 

□  Conceptual  model 

□  Logical  data  model 

□  Attributed  data  model 

□  Request  for  Change  in 
Standard  Metadata) 

Date  of  Submittal  from 
Developer/Requester  to  DA: 


Metadata  Item  Type 

□  Entity, 

□  Relationship, 

□  Attribute  or  Data 
Element) 

n  Other:  _ 

CASE  tool  and  version 
used:  * 


Version  number  and  date  of  the  fleet  logistics 
standard  data  model  referenced  by  this  request  or 
submittal: 


CDRL  Number(s)  of 
Related  DBDD(s)  and 
IDD(s):  * 


Other  identifiers:  I _ 1__ 

*  Not  applicable  for  requests  submitted  by  data  stewards  or  Quality  Action  Teams. 


Fleet  logistics  data  administration  has  found  the  following  discrepancy  in  the  metadata  request 
identified  above.  Please  correct  the  indicated  discrepancy,  re-check  the  item,  and  re-submit. 


Discrepancy  Level: 

□  Submittal  Packaging,  Labeling,  and  Format 

□  Names  and  Aliases 

□  Congruence  with  Standard  Data  Model 


□  Entities  and  Relationships 

□  Attributes  and  Definitions 

□  Other  Metadata: 


Discrepancy  Found: 


Recommended  Remedy: 


Transmittal 


DA  Name: 

DR  Response  Date: 

DA  Signature: 

Data  Steward(s): 

FL  DA  Req>  ID: 

DR  Transmitted  (Date) 

Transmitted  by: 

Attachments: 

Fleet  Logistics  Data  Administration  Program 


Data  Steward's  Log 


Steward: 


Information  Class: 
Dates: 


Loe-in  each  request  with  Req.  ID,  date,  req.  DA,  type,  and  suspense  date. 


Send  copy  of  log  to  DA  quarterly.  Retain  original  in  Data  Steward  records  for  5  years. 
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Fleet  Logistics  Data  Administration  Program 

Data  Steward's  Review  Response 

Steward:  Information  Class: 

Date: 

To  (DA): 

I  have  reviewed  your  request  number _ ,  dated _ . 

Subject  Matter  Experts  consulted: 


Findings 

Impact  on  CG  Information  Systems:  From  analysis  of  the  available  information  regarding  Coast  Guard 
information  systems,  the  proposed  change  will  have  the  following  effect(s): 


Therefore,  we  recommend  the  following  modifications  to  the  request  before  further  consideration  for 
acceptance: 


Legal,  Standards,  and  Business  Practice  Compliance:  From  review  of  the  applicable  laws,  regulations, 
standards,  and  professional  practices,  the  proposed  change  requires  the  following  change(s)  before  further 
consideration  for  acceptance: 


Enterprise  Metadata  Standards:  From  the  current  enterprise  data  model  as  it  pertains  to  this  information 
class,  the  proposed  change  must  be  modified  as  follows  before  further  consideration  for  acceptance: 


Recommendation 

In  light  of  the  above  findings,  we  recommend  the  following  action  regarding  this  request: 

□  Accept  the  request  as- written. 

□  Modify  the  request  as  indicated  and  re-submit. 

□  Deny  the  request  for  the  following  reason(s): 


(Data  steward's  signature  block) 


Fleet  Logistics  Data  Administration  Program 


Planning  Worksheet  for  Data  Conversion 

'Current  System: 

Version:  Release  Date:  Location: 
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APPENDIX  E 


Access 

control 

Account¬ 

ability 

Accreditation 


Acquirer 

AIS 


Alias 

Algorithm 

Approval 


GLOSSARY 


The  process  of  limiting  access  to  the  resources  of  an  AIS  only  to  authorized  persons, 
processes,  or  devices  (including  other  AIS’s  in  a  computer  network).  Access  control 
is  accomplished  through  use  of  appropriate  physical,  administrative,  and  technical 
controls. 

The  quality  or  state  which  enables  violations  or  attempted  violations  of  AIS  security 
to  be  traced  to  individuals  who  may  then  be  held  responsible. 

The  official  authorization  that  is  granted  to  an  AIS  to  process  classified  and  /or 
sensitive  information  is  its  operational  environment.  Accreditation  is  based  on  the 
determination  the  AIS  is  operating  at  an  acceptable  level  of  risk,  after  a 
comprehensive  security  evaluation  and  consideration  of  other  management  factors 
(e.g.,  criticality  of  operations,  cost  to  implement  controls,  impact  on  operations, 
planned  changes  in  AIS  operations.).  This  is  a  security  designation,  separate  from 
registration  as  a  standard  fleet  logistics  information  system. 

An  organization  that  procures  software  products  for  itself  or  another  organization. 

Automated  information  systems  include  traditional  ADP  systems  (mainframe  and 
minicomputers),  microcomputers,  office  information  systems,  networks  which 
cormect  them,  and  applications  (software)  which  run  on  them.  It  is  any  assembly  of 
computer  facilities,  equipment,  personnel,  software,  and  administrative  procedures 
configured  for  the  purpose  of  classifying,  sorting,  calculating,  computing, 
summarizing,  storing,  and  retrieving  data  and  information  with  a  minimum  of  human 
intervention. 

The  nonstandard  name  (that  is,  the  nonstandard  synonym)  of  a  data  element  used  in 
a  specific  information  system  at  a  specific  location.  [The  alias  will  be  used  to  bridge 
current  nonstandard  names  used  in  fielded  information  systems  or  external  data 
standards  to  the  DoD  standard  data  elements.  As  information  systems  are 
redesigned,  data  element  aliases  will  be  eliminated.] 

An  unambiguous  procedure  for  solving  a  problem  in  a  finite  number  of  steps. 

Written  notification  by  an  authorized  representative  of  the  acquirer  that  a  developer's 
plans,  design,  or  other  aspects  of  the  project  appear  to  be  sound  and  can  be  used  as 
the  basis  for  further  work.  Such  approval  does  not  shift  responsibility  from  the 
developer  to  meet  contractual  requirements. 


Glossary 


Architecture 

Attribute 

Attribute 

value 

Audit 


Audit  trail 

Authenti¬ 

cation 

Authorization 

Behavioral 

design 

Business  data 

Business 

rules 

CASE 


The  organizational  structure  of  a  system  or  CSCI,  identifying  its  components,  their 
interfaces,  and  a  concept  of  execution  among  them. 

A  property  or  characteristic  of  one  or  more  entities  (for  example:  color,  weight, 
sex).  Also,  a  property  inherent  in  an  entity  or  associated  with  that  entity  for 
database  purposes. 

The  data  value  given  to  an  attribute  (for  example:  The  attribute,  hair  color,  can  have 
an  attribute  value  of  brown. 

An  independent  review  and  examination  of  system  records  and  activities  in  order  to 
test  for  adequacy  of  system  controls,  to  ensure  compliance  with  established  policy 
and  operational  procedures,  and  to  recommend  any  indicated  changes  in  controls, 
policy,  or  procediu'es.  An  Internal  Audit  is  conducted  by  personnel  responsible  to 
the  management  of  the  organization  being  audited.  An  External  Audit  is  conducted 
by  an  organization  independent  of  the  one  being  audited. 

A  set  of  records  that  collectively  provide  documentary  evidence  of  processing  used 
to  aid  in  the  reconstruction,  review,  and  examination  of  the  sequence  of  events 
leading  towards  a  particular  final  result. 

The  process  of  establishing  the  validity  of  a  claimed  identity  of  a  subject  (person, 
process,  or  device)  to  verify  the  subject's  eligibility  to  access  specific  AIS 
assets,  most  often  categories  of  information. 

The  granting,  to  a  person,  process,  or  device,  the  right  of  access  to  an  AIS  asset. 
Authorization  frequently  refers  to  the  right  to  access  (read,  write,  modify,  create,  or 
delete)  data. 

The  design  of  how  an  overall  system  or  CSCI  will  behave,  from  a  user's  point  of 
view,  in  meeting  its  requirements,  ignoring  the  internal  implementation  of  the 
system  or  CSCI.  This  design  contrasts  with  architectural  design,  which  identifies 
the  internal  components  of  the  system  or  CSCI,  and  with  the  detailed  design  of  those 
components. 

Data  that  supports  the  business  processes  of  the  enterprise. 

The  restrictions  and  logical  links  that  describe  the  relationship  between  two  or  more 
data  elements.  For  example,  a  purchase  order  line  item  can  belong  to  only  one 
purchase  order  number.  A  vessel  name  can  be  associated  with  only  one  hull 
number. 

Computer-Aided  Software  Engineering,  which  refers  to  a  suite  of  tools  to 
accomplish  business  process  analysis,  functional  decomposition,  data  flow  analysis, 
data  element  definition,  state  transition,  modeling,  user  interface  construction,  and 
prototype  code  generation.  Analysis,  modeling,  and  prototyping  tools  are  referred  to 
as  “upper  CASE,”  while  code  generation,  performance  analysis,  middleware, 
conversion,  and  similar  technical  tools  are  referred  to  as  “lower  CASE.” 
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CDiF 


Character- 

string 

Class  name 


Class  word 

Classified 

information 


Compromise 


Computer 

Graphics 

Metafile 

(CGM) 

Conceptual 
data  model 

Conceptual 

schema 

Confidential 


CASE  Data  Interchange  Format,  a  standard  that  can  be  used  for  importing  and 
exporting  diagrams,  data  dictionary  information,  and  CASE  projects  between  a 
variety  of  CASE  tools.  CDIF  was  developed  in  1986  by  Cadre  Technologies,  and 
has  since  been  adopted  by  several  CASE  vendors  as  an  import  -  export  interface. 

A  series  of  characters.  The  term  “characters”  typically  includes  alphabetic,  numeric, 
and  special  characters  (unless  otherwise  indicated). 

The  specific  class  of  data  (for  example:  dimension,  identifier,  code)  that  is  stored  in 
data  items  of  a  standard  data  element  associated  with  a  particular  generic  element. 

See  Class  name. 

Official  information  which  requires  protection  against  unauthorized  disclosure  in  the 
interests  of  the  national  security  of  the  United  States,  and  which  has  been  so 
designated  in  accordance  with  the  provisions  of  Executive  Order  12356. 
COMDTINST  M5500.1 1  and  M55 10.21  provide  CG  policy  and  guidance  for  the 
handling  of  classified  information.  Storage  media  containing  classified  data  require 
external  and  internal  markings.  Except  in  time  of  national  defense  emergency 
condition,  only  the  Commandant  (G-C)  and  the  Chief,  Office  of  Law  Enforcement 
and  Defense  Operations  (G-0)  have  the  authority  to  originally  classify  information. 
See  Confidential,  Secret,  and  Top  Secret. 

Disclosure  of  classified  information  to  a  person  who  is  not  authorized  access  to  that 
information.  Compromise  can  occur  to  Level  1  or  Level  2  data  types.  Unauthorized 
disclosure  may  have  occurred  unknowingly,  willfully,  or  through  negligence.  The 
compromise  of  classified  information  presents  a  threat  to  national  security. 

A  vendor-independent  standard  for  transferring  vector  graphics  between 
applications.  CGM  follows  FIPS  128. 


A  data  model  that  is  concerned  with  concepts  and  knowledge  within  a  universe  of 
discourse. 

A  schema  that  defines  a  conceptual  model  of  a  database. 


A  Classification  designation  applied  to  information  or  material,  the  unauthorized 
disclosure  of  which  could  reasonably  be  expected  to  cause  identifiable  damage  to 
the  national  security.  Examples  of  "damage"  include  the  compromise  of  information 
which  indicates  the  strength  of  ground,  air  and  naval  forces  in  the  United  States  and 
overseas  areas;  disclosure  of  technical  information  used  for  training,  maintenance 
and  inspection  of  classified  munitions  of  war;  revelation  of  performance 
characteristics,  test  data,  design  and  production  data  on  munitions  or  war. 
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Confident!' 

ality 


Configuration 


Configuration 

item 

Configuration 

management 

(CM) 


Cross- 
Functional 
System  (CFS) 

CSCI 


Data 


Data 

administra¬ 
tion  (DA) 


Data 

administrator 

(DA) 

Data 

aggregation 


A  concept  that  applies  to  data  that  must  be  held  in  confidence  and  that  describes  the 
status  and  degree  of  protection  that  must  be  provided  for  such  data  about  individuals 
as  well  as  organizations.  Examples  of  data  confidentiality  include  data  that  is 
subject  to  the  Privacy  Act  and  proprietary  data  that  is  governed  by  nondisclosure 
agreements. 

The  physical  and  logical  elements  of  an  information  system,  and  the  manner  in 
which  they  are  organized  and  connected.  The  term  may  refer  to  hardware  or 
software  (including  data). 

An  element  of  a  configuration  that  is  subject  to  configuration  management. 


(or  Configuration  Control,  or  Change  or  Version  Control)  A  discipline  applying 
technical  and  administrative  direction  and  surveillance  to  (a)  identify  and  document 
the  functional  and  physical  characteristics  of  a  configuration  item,  (b)  control 
changes  to  those  characteristics,  and  (c)  record  and  report  change  processing  and 
implementation  status. 

An  information  system  that  supports  organizational  processes  relating  the  activities 
of  several  programs  or  functional  divisions,  rather  than  activities  of  a  single 
program. 

Computer  Software  Configuration  Item;  a  unit  of  an  information  system  that  is 
defined  and  managed  separately.  Usually  a  CSCI  is  a  major  functional  unit  of  a 
larger  system. 

A  representation  of  facts,  concepts,  or  instructions  in  a  formalized  manner  suitable 
for  communication,  interpretation,  or  processing  by  humans  or  by  automatic  means. 
“Information”  is  data  that  is  placed  in  a  meaningful  context. 

The  activity  that  assures  the  cost-effective  availability  of  data  to  support  the  cost- 
effective  operation  of  functions.  DoD  8320.1  describes  DA  as  "...  procedures, 
guidelines,  and  methods  for  effective  data  planning,  analysis,  standards,  modeling, 
configuration  management,  storage,  retrieval,  protection,  validation,  and 
documentation."  The  fleet  logistics  DA  program  includes  a  data  modeling  and  data 
element  definition  process,  data  administrators,  data  stewards,  a  tailored  set  of 
standards  and  guidelines,  and  a  repository.  Section  2  describes  the  components  of 
the  DA  program. 

The  role  responsible  for  carrying  out  the  procedures  identified  in  this  manual. 


A  collection  of  data  primitives  or  other  collected  data.  Data  aggregation  is  used 
typically  in  “rolled-up”  reports,  summarizing  a  collection  of  comparable  data  values. 
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Data 

architecture 


Data 

contamination 


Data- 

dependent 


Data 

dictionary 


Data  element 


Data  element 
alias 

Data  element 
standardi¬ 
zation 

Data  entity 


Data  integrity 


Data 

management 


Data  mapping 


Data 

Migration 


The  framework  for  organizing  and  defining  the  interrelationships  of  data  in  support 
of  an  organization's  missions,  functions,  goals,  objectives,  and  strategies.  Data 
architectures  provide  the  basis  for  the  incremental,  ordered  design  and  development 
of  systems  of  subject  databases  based  on  successively  more  detailed  levels  of 
data  modeling. 

A  deliberate  or  accidental  act  or  process  that  results  in  a  change  in  the  integrity  of 
the  original  data.  Contamination  can  include  inclusion  of  inaccurate  or  nonstandard 
values,  or  by  introducing  errors  that  make  the  data  unreadable. 

Protection  of  data  at  a  level  commensurate  with  the  sensitivity  level  of  the  individual 
data  elements,  rather  than  with  the  sensitivity  of  the  entire  file  which  includes  the 
data  elements. 

(a)  A  specialized  type  of  database  containing  metadata  that  is  managed  by  a  data 
dictionary  system,  (b)  A  repository  of  information  describing  the  characteristics  of 
data  used  to  design,  monitor,  document,  protect,  and  control  data  in  information 
systems  and  databases. 

A  template  for  determining  how  data  is  described  and  stored.  A  data  element  name 
is  the  name  for  the  data  matching  the  template.  A  data  element  may  have  a  standard 
name  (see  Standard  Data  Element)  or  a  nonstandard  name  (see  Nonstandard  Data 
Element). 

See  alias. 


The  process  of  evolving  the  specificity  of  a  standardization  data  element  to  the  point 
where  it  is  unique  and  its  name  is  unambiguous. 


In  a  data  model,  an  object  (person,  place,  thing,  or  concept)  about  which  an 
organization  wishes  to  maintain  information. 

The  state  that  exists  when  the  accuracy,  completeness,  timeliness,  and 
synchronization  of  the  data  is  of  the  highest  achievable  technical  validity. 

The  function  of  managing  data  used  in  manual  or  automatic  information  systems.  It 
includes  the  activities  of  strategic  data  planning,  data  element  standardization, 
information  management  control,  data  security,  data  synchronization,  and  database 
development  and  maintenance.  See  also  Data  Administration. 

Matching  a  data  field  in  a  legacy  system  (definition  and  attributes)  to  a  standard  data 
element  name,  definition,  and  attributes.  The  "map"  is  the  document  that  shows  the 
translation  between  legacy  system  fields  and  standard  data  elements. 

Matching  a  data  field  in  a  legacy  system  (definition  and  attributes)  to  a  standard  data 
element  name,  definition,  and  attributes.  The  "map"  is  the  document  that  shows  the 
translation  between  legacy  system  fields  and  standard  data  elements. 
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Data  model 


Data  model 
diagram 

Data  quality 


Data 
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Data 
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capability 

Data  security 


Data 
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zation 

Data  type 


Data  Type 
(Levels  I,  II, 
III) 


Data  value 
Data  view 


A  graphical  and  textual  representation  of  the  data  and  data  relationships  needed  by 
an  organization  to  achieve  its  missions,  functions,  goals,  objectives  and  strategies, 
and  to  manage  and  operate  the  organization. 

A  diagram  that  shows  a  collection  of  data  entities  that  belong  to  the  user's 
environment  along  with  the  relationships  between  them. 

The  correctness,  timeliness,  accmacy,  completeness,  relevance,  and  accessibility  that 
make  data  appropriate  for  use. 

A  specialized  type  of  database  containing  information  about  data,  such  as  meaning, 
relationships  to  other  data,  origin,  usage,  and  format,  and  including  all  the  important 
information  resources  needed  by  an  organization. 

The  means  by  which  data  is  retired  from  operational  usage,  and  preserved  for  later 
use. 


All  procedmes,  policies,  standards,  and  processes  performed  by  data  management 
personnel  for  the  purpose  of  safeguarding  data  from  unauthorized  access  or  use. 
Data  security  is  required  to  ensure  the  protection  of  data  from  unauthorized 
(accidental  or  intentional)  modification,  destruction,  or  disclosure,  and  that  data  is 
available  when  and  where  planned.  The  data  administration  component  is  the 
addition  of  access  information  to  data  element  definitions,  thereby  ensuring  that  all 
uses  of  the  data  element  will  be  subject  to  the  same  access  restrictions. 

The  state  in  which  the  timeliness  of  data  in  the  database  is  compatible  with  current 
requirements  for  that  data.  Typically,  synchronization  refers  to  the  sequence  in 
which  data  values  must  be  updated  to  preserve  data  integrity. 

Specifies  the  categorization  of  an  abstract  set  of  possible  values,  characteristics,  and 
set  of  operations  for  a  standard  data  element.  Integers,  real  numbers,  character 
strings,  and  enumerations  are  examples  of  data  types. 

Three  categories  of  data  used  to  determine  the  degree  of  protection  to  be  afforded 
data  and  automated  information  systems  processing  such  data.  This  is  a  CG 
categorization  which  groups  other  recognized  data/information  categories  for  the 
convenience  of  prescribing  automated  information  system  security  requirements. 

a.  Level  1.  Classified  data. 

b.  Level  II.  Unclassified,  sensitive  data  requiring  special  protection;  for 
example.  Privacy  Act,  For  Official  Use  Only,  technical  documents  restricted  to 
limited  distribution. 

c.  Level  III.  All  other  unclassified  data. 

Qualitative  and  quantitative  data  expressions  that  represent  the  contents  of  a  data 
element. 

A  subset  of  a  conceptual,  logical,  or  physical  data  model  that  is  used  by  a  process, 
procedure,  data  store,  or  external  agent. 
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Database 
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system 


Design 


Developer 


Disclosure 


Domain 


Enterprise 


A  collection  of  interrelated  data,  often  with  controlled  redundancy,  organized 
according  to  a  schema  to  serve  one  or  more  applications.  The  data  is  stored  so  that  it 
can  by  used  by  different  programs  without  concern  for  the  data  structure  or 
organization. 

The  activity  responsible  for  the  enforcement  of  the  policies  and  standards 
established  by  the  Data  Administrator,  to  include  providing  technical  support  for 
physical  database  definition,  design,  implementation,  maintenance,  integrity,  and 
security,  and  coordinating  with  computer  operations  technicians,  system  developers, 
vendors  and  users.  Database  administration  is  oriented  toward  technical  support  for 
databases  and  the  effective  and  efficient  use  of  information  technology  resources. 

The  role  providing  technical  support,  including:  enforcing  the  policies  and 
standards  set  by  the  data  administrator  (DA)  for  the  database;  providing  technical 
support  for  database  definition,  design,  maintenance,  and  integrity;  and  coordinating 
with  computer  operations  technicians,  system  developers,  vendors,  and  users. 

The  structure  that  portrays  relationships  between  and  among  all  elements  of  the 
database. 

A  computer  based  system  used  to  establish,  make  available,  and  maintain  the 
integrity  of  a  database.  The  system  may  be  invoked  by  non-programmers  or  by 
application  programs  to  define,  create,  revise,  retire,  interrogate,  and  process 
transactions,  and  to  update,  back  up,  recover,  validate,  secure,  and  monitor  the 
database. 

Those  characteristics  of  a  system  or  CSCI  that  are  selected  by  the  developer  in 
response  to  the  requirements.  Some  will  match  the  requirements;  others  will  be 
elaborations  of  requirements,  such  as  definitions  of  all  error  messages  in  response  to 
a  requirement  to  display  error  messages;  others  will  be  implementation  related,  such 
as  decisions  about  what  software  units  and  logic  to  use  to  satisfy  the  requirements. 

An  organization  that  creates  or  develops  software  products  ("develops"  may  include 
new  development,  modification,  reuse,  reengineering,  maintenance,  or  any  other 
activity  that  results  in  software  products).  The  developer  may  be  a  contractor  or  a 
Government  agency. 

(unauthorized)  The  unauthorized  release  or  access  of  Level  I  or  II  data  to  someone 
lacking  proper  clearance  and  a  need  to  know.  Also  see  Compromise. 

A  generic  or  specific  set  of  acceptable  values  a  data  value  is  allowed  to  have. 
Examples  of  domains  include  the  alphabet,  yes/no,  numbers  one  through  ten,  or  a  set 
of  transaction  identifiers. 

An  identifiable  organization  that  works  together  to  accomplish  a  mission.  The  scope 
of  the  enterprise  is  likely  to  evolve  over  time  as  the  requirement  and  opportunity  for 
information  sharing  increases.  Use  of  the  term  “enterprise”  in  this  manual  refers 
exclusively  to  the  fleet  logistics  enterprise,  not  the  corporate  CG  enterprise  as  a 
whole. 
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Information 


A  model  that  shows  the  activities  and  processes  that  are  necessary  in  running  the 
enterprise. 

A  description  of  the  categories  of  information  (entities)  and  the  relationships  of  that 
information,  as  it  is  used  throughout  the  enterprise.  It  includes  definitions, 
attributes,  and  domains  for  the  data  elements  in  the  model.  When  the  enterprise  data 
model  is  fleshed  out  with  data  element  detail  (the  attributed  data  model),  then 
designers  of  individual  systems  can  select  from  the  central  standard  (the  enterprise 
data  encyclopedia)  the  definitions  they  need  to  build  their  respective  application  data 
models  and  physical  databases. 

A  person,  place,  thing,  concept,  event,  or  activity  about  which  an  organization 
wishes  to  keep  information. 

A  modeling  technique  that  employs  diagrams  to  illustrate  the  associations  or 
relationships  among  entities.  E-R  diagrams  pictorially  illustrate  entities,  their  key 
attributes,  and  their  relationships. 

The  process  of  determining  whether  an  item  or  activity  meets  specified  criteria. 

A  logical  description  of  an  enterprise  that  may  differ  from  the  conceptual  schema 
upon  which  it  is  based  in  that  some  entities,  attributes,  or  relationships  may  be 
omitted,  renamed,  or  otherwise  changed. 

A  set  of  related  records  treated  as  a  unit. 

Information  designation  assigned  to  unclassified  official  information  of  a  privileged, 
proprietary,  or  personal  nature  which  must  be  protected  against  unauthorized  public 
release.  Release  of  FOUO  information  must  be  accomplished  in  accordance  with 
Freedom  of  Information  Act  directives. 

Fleet  logistics  is  not  a  single  CG  organization,  but  is  a  collection  of  supply, 
maintenance,  and  shipboard  configuration  management  functions  that  have  created  a 
community  of  interest  across  several  organizations.  The  use  of  this  generic  term  is 
meant  to  emphasize  the  critical  nature  of  the  information  shared  by  fleet  logistics 
functions. 

Government  Open  Systems  Interconnect  Profile,  FIPS  146 

Independent  verification  and  validation  (IV&V).  Systematic  evaluation  of  software 
products  and  activities  by  an  organization  that  is  not  responsible  for  developing  the 
product  or  performing  the  activity  being  evaluated. 

The  meaning  that  is  assigned  to  data  by  persons  who  are  aware  of  the  known 
conventions  used  in  its  representation.  Information  is  a  shared  resource  and  is  not 
owned  by  any  organization  unless  restricted  by  security,  sensitivity,  or  proprietary 
rights. 
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A  category  of  logically  related  information  that  supports  the  things  of  lasting  interest 
the  organization  wishes  to  keep  data  about.  Information  classes  are  created  when  the 
information  requirements  of  a  process  are  defined. 


The  imposition  of  engineering  discipline  on  the  development  of  information/data 
systems.  A  highly  disciplined  approach  that  includes  a  set  of  standard  techniques 
and  procedures  imposed  on  all  life  cycle  stages. 

A  model  that  represents  the  processes,  entities,  information  flows,  and  elements  of 
an  organization  and  all  relationships  between  these  factors. 


A  product  containing  information  that  is  used  for  decision  making  or  problem 
solving. 

An  object  that  is  concerned  with  the  handling,  usage,  or  presentation  of  information. 


All  information  created  manually  or  by  automated  means  that  an  enterprise  treats  as 
a  resource  for  decision  making  and  problem  solving.  Information  resources 
encompass  information  and  the  assets  which  store,  process,  maintain,  and  manage 
information.  These  resources  include  hardware,  telecommunications,  system 
software,  applications,  data,  policies,  and  procedures. 

The  policy,  action,  and  procedures  concerning  information,  both  automated  and  non- 
automated,  that  management  establishes  to  serve  the  current  and  future  needs  of  an 
enterprise.  COMDTINST  5230.41  states  that  “information  resources  will  be 
managed  as  any  other  Coast  Guard  assets,  and  will  not  be  treated  as  free  goods.” 

A  description  of  data  as  it  is  physically  stored,  including  all  aspects  of  the 
environment  where  a  database  resides. 

(or  Data  Security)  The  security  that  is  required  to  assure  the  protection  of  data  from 
unauthorized  (accidental  or  intentional)  modification,  destruction,  or  disclosure,  and 
that  data  is  available  when  and  where  planned.  The  data  administration  component 
is  the  addition  of  access  information  to  data  element  definitions,  thereby  ensuring 
that  all  uses  of  the  data  element  will  be  subject  to  the  same  access  restrictions. 

In  software  development,  a  relationship  among  two  or  more  entities  (such  as  CSCI- 
CSCI,  CSCI-HWCI,  CSCI-user,  or  software  unit-software  unit)  in  which  the  entities 
share,  provide,  or  exchange  data.  An  interface  is  not  a  CSCI,  software  unit,  or  other 
system  component;  it  is  a  relationship  among  them.  Interfaces  that  permit  the 
exchange  of  data  are  documented  in  Interface  Description  Documents  (IDD),  which 
are  reviewed  by  DA. 

Information  Resource  Dictionary  System  (FIPS  156),  a  standard  for  evaluating  the 
capabilities  of  metadata  repositories.  IRDS  is  the  CG  data  dictionary  standard. 
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Joint  review  A  process  or  meeting  involving  representatives  of  both  the  acquirer  and  the 

developer,  during  which  project  status,  software  products,  and/or  project  issues  are 
examined  and  discussed. 

An  information  system  that  is  not  part  of  the  current  standard,  that  is,  one  which  was 
inherited  and  must  be  utilized  as-is.  From  a  data  administration  point  of  view, 
legacy  systems  are  likely  to  contain  nonstandard,  and  therefore  unreliable,  data 
values.  To  be  used  by  standard  systems,  the  data  from  legacy  systems  must  be 
migrated  to  the  standard,  or  an  interface  must  be  mapped  between  the  standard  data 
resource  and  the  legacy  system. 

Literal  data  Clear  text  representation  of  a  data  value  that  requires  no  translation  before  use. 

Logical  data  A  representation  of  the  information  requirements  of  an  organization.  The  model  is 

model  formed  by  arranging  the  data  into  a  logical  structure  that  is  independent  of  how  the 

data  is  to  be  used. 

Logical  Describes  the  objects  (entities),  the  attributes  of  those  objects,  and  the  relationships 

Database  between  the  objects.  The  LDBD  provides  the  complete,  normalized  set  of  logical 

Design  tables  necessary  to  support  the  functions  of  an  organization. 

(LDBD) 

Logical  -to-  This  type  of  map  links  the  legacy  (physical)  data  element  to  the  appropriate  standard 
physical  data  data  element  in  the  fleet  logistics  logical  data  model.  The  attribute  name  from  the 

mapping  fleet  logistics  logical  data  model  is  given  to  the  appropriate  legacy  data  element. 

Logical-to-physical  mapping  is  applied  to  legacy  data  elements  that  must  be 
standardized  (for  sharing,  reference,  compatibility  with  imported  data  or  other 
requirement). 

Metadata  Information  that  describes  the  attributes  or  characteristics  of  data  such  as  definition, 

source,  format,  range  of  values,  where  and  how  the  data  is  used,  and  the  organization 
responsible  for  the  data.  Metadata  is  often  defined  as  data  about  data;  that  is 
information  about  data  that  is  stored  in  data  dictionaries,  data  models,  schema,  and 
their  computerized  representations. 

Migration  An  information  system  for  which  a  successor  is  planned  or  is  in  development,  and 

system  from  which  data  must  be  transferred  and  converted  to  the  new  standard. 

Model  A  structured  representation  of  physical  objects,  concepts,  and/or  a  system  that  helps 

organize,  clarify,  and  unify  knowledge.  A  model  contains  a  system  of  rules,  data, 
and  inferences  presented  as  a  formal,  logical  description  of  a  system  of  objects  and 
their  states  of  affairs  or  interactive  behavior.  A  model  also  facilitates  analysis, 
experimentation,  simulation,  or  comprehension. 

National  Information  or  material,  the  unauthorized  disclosure  if  which  could  reasonably  be 

security  expected  to  cause  damage  to  the  national  defense,  and  which  usually  bears  a  security 

information  classification. 
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Any  data  element  that  exists  in  a  system  or  application  program  and  does  not 
conform  to  the  conventions,  procedures,  or  guidelines  established  by  the  DoD  Data 
Administrator. 

The  necessity  for  access  to,  knowledge  of,  or  possession  of  certain  information 
required  to  carry  out  official  duties.  Responsibility  for  determining  whether  a 
person's  duties  require  that  possession  of  or  access  to  such  information  and  whether 
the  individual  is  authorized  to  receive  it  rests  upon  the  individual  having  current 
possession,  knowledge,  or  control  of  the  information  involved  and  not  upon  the 
prospective  recipient(s). 

The  process  of  decomposing  more  complex  data  structures,  according  to  a  set  of 
dependency  rules,  in  order  to  derive  simpler,  more  stable,  data  structures. 

(or  DATA)  Any  item  of  information  about  a  person  that  is  not  a  matter  of  public 
record  and  is  usually  considered  to  be  personal  to  an  individual.  It  includes  but  is 
not  limited  to:  social  security  number  (SSN),  information  about  the  individual's 
financial,  family,  social,  and  recreational  affairs,  the  individual's  medical, 
educational  (except  military  training),  employment,  political,  or  criminal  history, 
information  that  identifies,  describes,  or  gives  a  basis  for  inferring  personal 
characteristics. 

The  form  in  which  the  database  is  physically  stored  on  the  storage  media,  including 
all  pointers  or  other  means  by  which  the  data  interconnects. 

A  physical  representation  of  one  or  more  real  world  objects. 


Portable  Operating  System  Interface  Definition  (FIPS  151),  provides  a  standard  for 
reusable  code  (to  the  system  call  level)  that  is  portable  across  many  vendors’ 
computers  and  operating  systems. 

The  right  of  an  individual  to  determine  for  himself  when,  how,  and  to  what  extent 
information  about  him  can  be  obtained  or  communicated  to  others.  Privacy  also 
includes  the  right  of  individuals  to  know  that  recorded  information  is  accurate, 
pertinent,  complete,  up  to  date,  and  reasonably  secure  from  unauthorized  access, 
either  accidental  or  intentional.  Privacy  Act  regulations  restrict  the  types  of 
information  that  can  be  collected  and  stored  about  an  individual,  and  under  what 
conditions  the  information  may  be  released. 

A  prescribed  sequence  of  business  actions. 

An  organized  set  of  related  tasks  that  use  the  resources  of  the  business  to  produce 
specified  results  and  that  comprise  a  repeatable  sequence  of  activities  that  have 
measurable  input(s),  value  -  added  activities,  and  measurable  output(s). 
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A  formal,  logical  representation  of  process  task  sequences  and  relationships.  A 
process  model  includes  representations  and  relationships  of  data  inputs  and  outputs, 
process  control  rules,  input  materials,  and  product  output.  It  also  represents  the 
mechanisms  and  other  resources  employed  in  the  tasks  and  identifies  the  responsible 
roles. 

Testing  performed  to  demonstrate  to  the  acquirer  that  a  CSCI  or  a  system  meets  its 
specified  requirements. 

A  data  value  that  is  a  non-numerical  description  of  an  entity. 


Numerical  expressions  upon  which  mathematical  operations  can  be  performed. 


The  process  of  examining  and  altering  an  existing  system  to  reconstitute  it  in  a  new 
form.  May  include  reverse  engineering  (analyzing  a  system  and  producing  a 
representation  at  a  higher  level  of  abstraction,  such  as  design  from  code), 
restructuring  (transforming  a  system  from  one  representation  to  another  at  the  same 
level  of  abstraction),  re-documentation  (analyzing  a  system  and  producing  user  or 
support  documentation),  forward  engineering  (using  software  products  derived  from 
an  existing  system,  together  with  new  requirements,  to  produce  a  new  system),  re¬ 
targeting  (transforming  a  system  to  install  it  on  a  different  target  system),  and 
translation  (transforming  source  code  from  one  language  to  another  or  from  one 
version  of  a  language  to  another). 

For  fleet  logistics  information  systems,  the  process  by  which  DA  indicates  that  the 
data  values  in  a  specific  system  meet  the  enterprise  metadata  standard,  and  are 
therefore  shareable  as  part  of  the  enterprise  information  resource. 

An  association  between  two  entities. 

A  database  of  knowledge  about  an  enterprise,  its  goals,  entities,  records, 
organizational  units,  functions,  processes,  procedures,  and  application  and 
information  engineering.  (A  dictionary  contains  names  and  descriptions  of  data 
items,  processes,  data  handling  facilities,  etc.)  A  repository  contains:  (a)  complete 
coded  representations  of  plans,  models,  and  designs  with  tools  for  cross  checking, 
correlation  analysis,  and  validation  and  (b)  many  rules  relating  to  knowledge  stored 
and  how  to  employ  rule  processing  (the  artificial  intelligence  technique)  to  help 
achieve  accuracy,  integrity,  and  completeness  of  the  plans,  models,  and  designs. 
Thus,  it  is  a  knowledge  base  that  not  only  stores  development  information  but  also 
helps  to  control  its  accuracy  and  validity. 
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Shows  the  three  levels  of  metadata  in  the  fleet  logistics  metadata  repository: 

•  Conceptual  data  architecture:  describes  the  kinds  of  information  that  are 
of  interest  to  the  fleet  logistics  enterprise. 

•  Logical  data  model:  describes  the  logical  entities  and  data  elements  of  the 
enterprise  in  a  manner  that  is  independent  of  any  application  system  or 
physical  database  design. 

•  Physical  data  model:  describes  the  implementation  of  the  logical  data 
model  in  the  physical  database  designs  of  fleet  logistics  standard 
application  systems. 

This  three-tier  approach  is  described  in  greater  detail  in  Appendix  A. 

Note;  This  model  does  not  match  any  specific  commercial  repository  software  product.  It 

represents  the  requirements  for  three  levels  of  metadata  needed  by  the  DA  repository  function. 

Implementation  may  require  a  series  of  closely  linked  tools  rather  than  use  of  a  single  product. 

An  information  system  that  is  used  to  manage  the  content,  security,  and  quality  of 

the  repository  in  a  manner  that  supports  the  management  and  control  of  enterprise 

information  management  and  information  technology  resources. 

A  designated  area  of  accountability. 


(or  Risk  Analysis)  An  analysis  of  assets  and  vulnerabilities,  and  threats  to  those 
assets  to  determine  the  level  of  risk  to  an  AIS.  Risk  is  "measured"  either 
quantitatively  or  qualitatively  by  determining  the  impact  of  threats  on  the  facility, 
system,  information,  personnel,  and  supported  organizations  or  other  users. 

A  collection  of  responsibilities.  In  this  manual,  roles  such  as  data  administrator, 
configuration  manager,  data  steward,  developer,  and  maintainer  are  used  to  describe 
data  administration  functions  that  may  or  may  not  be  the  individual’s  primary  job 
responsibility. 

(1)  A  characteristic  that  a  system  or  CSCI  must  posses  in  order  to  be  acceptable  to 
the  acquirer.  (2)  A  mandatory  statement  in  a  standard  or  contract. 

A  description  or  global  model  of  the  structure  of  a  database. 

A  Classification  designation  applied  only  to  information  or  material  the 
unauthorized  disclosure  of  which  could  reasonably  be  expected  to  cause  serious 
damage  to  the  national  security.  Examples  of  "serious  damage"  include  disruption 
of  foreign  relations  significantly  affecting  the  national  security;  significant 
impairment  of  a  program  or  policy  directly  related  to  the  national  security;  revelation 
of  significant  military  plans  or  intelligence  operations'  compromise  of  significant 
military  plans  or  intelligence  operations;  and  compromise  of  significant  scientific  or 
technological  developments  relating  to  the  national  security. 
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The  effectiveness  level  of  the  controls  which  allow  access  to  an  AIS  such  that  only 
properly  authorized  individuals,  or  processes  operating  on  their  behalf,  will  have 
access  to  read,  write,  create,  or  delete  information,  or  interfere  with  the  timely 
processing  of  information. 

Also  the  measures  required  to  protect  against  unauthorized  (accidental  or 
intentional)  disclosure  modification  or  destruction  of  AIS’s  and  data  and  denial  of 
service  to  process  data.  Components  include  Physical  Security  Administrative 
Security  Personnel  Security  and  Technical  Security  (hardware  software  and 
communications).  See  definitions  for  each  item  listed. 

(or  Data)  Information  that,  as  determined  by  a  competent  authority,  must  be 
protected  because  its  unauthorized  disclosure,  alteration,  loss,  or  destruction  will  at 
least  cause  perceivable  damage  to  someone  or  something.  Classified  information, 
which  is  also  sensitive  information,  is  always  designated  as  classified. 

An  abbreviated  designation  commonly  used  for  unclassified,  sensitive  information. 
This  type  of  information  includes,  but  is  not  limited  to,  certain  personal,  budget, 
financial  and  management  information,  and  information  generally  categorized  as  For 
Official  Use  Only  (e.g.,  proprietary  and  privileged  information).  A  generic 
designation  for  unclassified  information  that  must  be  protected  from  unauthorized 
disclosure,  alteration,  loss,  or  destruction  because  it  would  cause  perceivable 
damage  to  someone  or  something.  This  type  of  information  includes  but  is  not 
limited  to  certain  personal,  budget,  financial  and  management  information,  and 
information  generally  categorized  as  For  Official  Use  Only  (e.g.,  proprietary  and 
privileged  information). 

Computer  programs  and  computer  databases.  Note:  Although  some  definitions  of 
software  include  documentation,  MIL-STD-498  limits  the  definition  to  computer 
programs  and  computer  databases  in  accordance  with  Defense  Federal  Acquisition 
Regulation  Supplement  227.401. 

A  set  of  activities  that  results  in  software  products.  Software  development  may 
include  new  development,  modification,  reuse,  reengineering,  maintenance,  or  any 
other  activities  that  result  in  software  products. 

The  set  of  activities  that  enables  responsibility  for  software  development  to  pass 
from  one  organization,  usually  the  organization  that  performs  initial  software 
development,  to  another,  usually  the  organization  that  will  perform  software  support. 

An  exact  value,  a  physical  entity,  or  an  abstract  concept  established  and  defined  by 
authority,  custom,  or  common  consent  to  serve  as  a  reference,  model,  or  rule  in 
measuring  quantities  or  qualities,  establishing  practices  or  procedures,  or  evaluating 
results. 

The  name  of  a  data  element  that  was  derived  from  a  data  model,  and  whose  name 
and  attributes  were  standardized  according  to  the  data  standards  and  conventions 
established  by  the  DoD  Data  Administrator  (DA). 
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The  process  for  evolving  a  standard.  Standardization  requires  comparing  and 
reconciling  the  details  of  each  item  with  those  of  related  items  and  with  intended  or 
normalized  criteria. 

A  method  that  takes  a  long-range  view  of  the  enterprise’s  data  requirements  and 
provides  intermediate  steps  to  achieve  the  long-range  goal.  Strategic  data  planning 
advocates  separation  of  data  from  the  applications  that  create  and  process  the  data, 
establishment  of  subject  area  databases,  and  agreement  on  validated  standard 
metadata  definitions.  In  most  approaches,  proactive  data  administration  starts  with 
strategic  data  planning.  Strategic  data  planning  recognizes  the  enterprise's  data  as  a 
resource  that  is  separate  from  the  enterprise's  organizations,  functions,  locations,  or 
software  systems.  In  addition,  the  strategic  planners  estimate  the  scope  of  the 
corporate  data  resource  thirty  years  or  more  into  the  future,  and  attempt  to  predict 
which  other  organizations  will  be  included  in  data-sharing  arrangements. 

A  vendor-independent  language  for  submitting  data  display  and  report  requests  to 
various  database  management  systems.  SQL  follows  FIPS  127-1.  SQL  is  the  CG 
data  management  and  data  access  standard. 


A  rational,  logical  grouping  of  data  related  to  a  common  business  activity. 

A  word,  expression,  or  symbol  accepted  as  a  figurative  or  symbolic  substitute  for 
another  word  or  expression;  that  is,  and  alternative  name  for  the  same  thing.  See 
“Alias.” 

An  organization  of  physical,  information,  personnel,  and  managerial  assets  which  is 
directed  toward  some  common  purpose.  The  key  words  are  “organization”  and 
“purpose.”  These  provide  the  unity,  direction,  and  control  which  distinguish 
systems  from  mere  collections  of  resources. 

One  or  more  words  or  symbol  sets  referenced  as  a  unit. 

A  classification  designation  applied  only  to  information  or  material  the  unauthorized 
disclosure  of  which  could  reasonably  be  expected  to  cause  exceptionally  grave 
damage  to  the  national  security.  Examples  of  "exceptionally  grave  damage"  include 
armed  hostilities  against  the  United  States  or  its  allies;  disruption  of  foreign  relations 
vitally  affecting  the  national  security;  the  compromise  of  vital  national  defense  plans 
or  complex  cryptologic  and  communications  intelligence  systems;  the  revelation  of 
sensitive  intelligence  operations;  and  the  disclosure  of  scientific  or  technological 
developments  vital  to  the  national  security. 

Data  stored  in  an  information  system  that  can  be  transferred  or  accessed  by  another, 
separately  developed  information  system  transparently,  that  is,  without  analysis, 
interpretation,  mapping,  or  conversion,  while  maintaining  data  quality.  Transparent 
sharing  of  data  requires  that  both  systems  have  been  designed  and  built  using  the 
same  (standard)  logical  data  model,  data  element  names,  and  data  element 
definitions. 
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Unclassified 

User 

Validation 

View 


Information  that  does  not  require  protection  in  the  interest  of  national  security,  and 
so  does  not  require  the  classification  levels  of  Top  Secret,  Secret,  or  Confidential. 
Unclassified  information  can  be  subject  to  other  restrictions,  such  as  Privacy  Act, 
For  Official  Use  Only,  proprietary  or  trade  secret  nondisclosure,  or  procurement- 
sensitive. 

A  person  or  organization  receiving  products  or  services  produced  by  an  automated 
system  either  by  access  to  the  system  or  by  other  means.  Users  of  fleet  logistics 
standard  information  are  stakeholders  in  the  data  administration  process. 

The  process  of  checking  data  for  correctness  or  compliance  with  applicable 
standards,  rules,  and  policies. 

An  external  relation  consisting  of  attributes  retrieved  or  derived  from  other  attributes 
stored  in  one  or  more  base  relations  and  joined,  as  defined,  in  the  view  relation. 

All  the  words,  abbreviations,  or  phrases  of  a  language. 
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